This article explains how to import OpenSTLinux v3.0 projects supporting FIP, into STM32CubeIDE from version 1.6.1 on Linux workstation.
1 Overview[edit source]
It is possible to import into an existing STM32MP15 Project some OpenSTLinux projects:
- STM32CubeIDE 1.6.1 provides support for ecosystem release v3.0.0 .
- STM32CubeIDE 1.5.0 provides support for ecosystem release v2.1.0 .
- STM32CubeIDE 1.4.0 provides support for ecosystem release v2.0.0
This is done thanks to 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[edit source]
All the OpenSTLinux projects follow the same project structure approach with three main parts:
- Eclipse artifact, in order to ease project usage,
- Build artifact identifying clearly the project output,
- Sources, as they appear in Yocto environment
Device tree sources generated by STM32CubeMX into DeviceTree/ directory of 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 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[edit source]
Several Build targets are proposed for Linux project addressing device trees, module and kernel.
Double click on Build target launches the corresponding compilation with associated Yocto SDK.
It is then possible to update the running STM32MP15 target with the new build artifacts using the STM32 Cortex-A Linux Deployment Run Configuration menu.
In this dedicated Run Configuration menu, build artifact (device tree binary, module, kernel..) is added using Add... button and giving:
- 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 extlinux.conf target file in order to take it into account on the next target reboot, see Actions sub-window.
After download of build artifacts to the STM32MP15 board:
- a script can be executed (optional)
- STM32MP15 board is rebooted (default)
4 Other OpenSTLinux Projects[edit source]
From OpenSTLinux 3.0, boot architecture has been revisited as explained in TF-A overview. Now two objects are needed in order to update STM32MP15 flash 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 FIP image relies onto three projects, it exists some dependencies between TF-A, U-boot and OP-TEE.
all build target in those projects is launching fiptool which build the FIP image. This will succeed only if all the objects are generated.
A build target using generated device tree sources is also proposed inside STM32CubeIDE.
Those generated device trees are targeting only trusted mode so there is no support inside OP-TEE project.
As depicted in the figure below, we have the generated device tree sources for TF-A and U-boot inside DeviceTree/ directory. They are linked into project TF-A and U-boot and specific build targets are generated:
- stm32 (stm32mp157c-mymp157cdk2-mx) for TF-A project that has to be launched first,
- and all (stm32mp157c-mymp157cdk2-mx) for U-boot project.
FIP image for the generated device tree is then available from fip directory of FIP artifact.
Then, STM32MP15 board needs to be updated, typically using STM2CubeProgrammer.
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 