- Last edited 11 months ago ago
How to manage OpenSTLinux projects in STM32CubeIDE
This article explains how to import OpenSTLinux v3.0 projects supporting FIP, into STM32CubeIDE from version 1.6.1 on a Linux® workstation.
It is possible to import into an existing STM32MP15 project some OpenSTLinux projects:
- STM32CubeIDE 1.8.0 provides support for ecosystem release v3.1.0 .
- STM32CubeIDE 1.6.1 provides support for ecosystem release v3.0.0 .
This is done using the Import an OpenSTLinux project... Cortex®-A hierarchical project contextual menu, providing access to Linux®, TF-A, U-boot and OP-TEE.
2 OpenSTLinux project structure
All the OpenSTLinux projects follow the same project structure approach with three main parts:
- Eclipse artifact, in order to make project usage easier,
- Build artifact identifying clearly the project output,
- Sources, as they appear in the Yocto Project® environment
Device tree sources generated by STM32CubeMX into the DeviceTree/ directory of the Cortex®-A hierarchical project, are automatically included inside the corresponding OpenSTLinux projects: Linux®, TF-A and U-boot, with:
- source file links,
- dedicated Build target.
FIP is also supported, from release 1.6.1, which provides OpenSTLinux 3.0. The FIP_artifacts/ directory of the Cortex®-A hierarchical project hosts all deployment objects needed to build FIP image. Those objects are generated by TF-A, U-boot or OP-TEE projects.
3 Linux project
Several Build targets are proposed for Linux® project addressing device trees, module and kernel.
Double-click on Build target to launch the corresponding compilation with associated Yocto Project® SDK.
It is then possible to update the running STM32MP15 target with the new build artifacts using the STM32 Cortex-A Linux Deployment > Run Configurations... menu.
In this dedicated Run Configurations... menu, build artifact (such as device tree binary, module, kernel or other) is added using the Add... button and providing:
- Local path, on the Linux® workstation (here builld/arch/arm/boot/dts/stm32mp157-dk2f-mx-mx.dtb)
- Remote path, browsing the remote target file system
For a new device tree, it is possible to update the extlinux.conf target file to take it into account at the next target reboot, see the Actions sub-window.
After download of build artifacts to the STM32MP15 board:
- a script can be executed (optional)
- STM32MP15 board is rebooted (default)
4 Bootloader projects
From OpenSTLinux 3.0, the boot architecture has been revisited as explained in TF-A overview. Now two objects are needed to update the STM32MP15 Flash memory device: TF-A BL2 flash partition and FIP Image. Both of them are generated inside STM32CubeIDE:
- TF-A BL2 flash partition, available from TF-A project build artifact,
- FIP image, located into fip directory of FIP artifacts.
Since the FIP image relies onto three projects, some dependencies exist between TF-A, U-boot and OP-TEE. all build target in those projects is launching the fiptool, which builds the FIP image. This succeeds only if all the objects are generated.
A build target using generated device tree sources is also proposed inside STM32CubeIDE. These generated device trees are targeting only trusted mode so there is no support inside the OP-TEE project.
As depicted in the figure below, the generated device tree sources for TF-A and U-boot are inside the DeviceTree/ directory. They are linked into project TF-A and U-boot and specific build targets are generated:
- stm32 (stm32mp157c-mymp157cdk2-mx) for the TF-A project, which must be launched first,
- and all (stm32mp157c-mymp157cdk2-mx) for the U-boot project.
FIP image for the generated device tree is then available from the fip directory of FIP artifact.
From STM32CubeIDE release 1.8.0, it is possible to update bootlader objects (TF-A BL2 & FIP image) directly on a running MP15 target. Before working with STM32CubeIDE, it is recommended to first update MP15 boot flash with STM32CubeProgrammer.
All flash devices available on STM32MP157x-EV1 (SD-Card, eMMC, NAND & NOR) are supported by STM32CubeIDE. It is possible to update them, typically with customized device tree, thanks to integrated STM32CubeMX. Note that trusted image only is supported.
- SD card update with customized trusted image
- eMMC update with customized trusted image
- NAND update with customized trusted image
- NOR update with customized trusted image