1. Article purpose[edit | edit source]
The pieces of software delivered as source code within the OpenSTLinux Developer Package (for example the Linux kernel) can be modified. External out-of-tree Linux kernel modules, and pieces of applicative software (for example Linux applications) can also be developed thanks to this Developer Package, and loaded onto the board.
The build of all these pieces of software by means of the SDK for OpenSTLinux distribution, and the deployment on-target of the resulting images is explained below.
2. Cross-compiling with SDK[edit | edit source]
2.1. SDK-infos[edit | edit source]
Prerequisites:
SDK-infos is an optional component that facilitates build for the OpenSTLinux BSP packages. This directory contents a script and a README to help user to generate a build environment adapted to its needs and to manage OpenSTLinux components diversity.
The <SDK-infos installation directory>/README.HOW_TO.txt.<board flavor>[1] helper file gives instructions to:
☐ generate a helper script for one of STM32MP1 series' boards 
, STM32MP2 series' boards for A35-TD flavor and STM32MP2 series' boards for M33-TD flavor
☐ extract BSP source code according to the seleted board
☐ generate boot stage of Cortex-A
☐ generate binary to flashing via Cortex-A
☐ generate kernel and kernel modules
☐ generate m33 firmware for STM32MP2 series' boards for M33-TD flavor
It is mandatory to execute the build steps specified below.
The script "generated_build_script-stm32mpx.sh" uses the whole "README.HOW_TO.txt" files to generate a helper script to compile the component needed for your target.
- Different options are supported and can be accessed through script help:
$> ./generated_build_script-stm32mpx.sh help
generated_build_script <machine name>
<machine name>: name of the machine which can be use for sdk compilation
- stm32mp1 or stm32mp1-mx: to compile STM32MP1 series' boards either
- via device tree from components themselves or external-dt source
- or via device tree from components themselves or external board provided by STM32CubeMX
- stm32mp2 or stm32mp2-mx: to compile STM32MP2 series' boards for A35-TD flavor either
- via device tree from components themselves or external-dt source
- or via device tree from components themselves or external board provided by STM32CubeMX
- stm32mp2-m33td or stm32mp2-m33td-mx: to compile STM32MP2 series' boards for M33-TD flavor either
- via device tree from components themselves or external-dt source
- or via device tree from components themselves or external board provided by STM32CubeMX
- To generate a helper script for ST board (ex.: stm32mp257f-dk):
$> ./sdk-infos/generated_build_script-stm32mpx.sh stm32mp2
This command generates a script on root directory for all source codes from Developer Package: sources/*/sdk_compilation-stm32mp2-my-custom-board.sh
- To generate a helper script for board with Cube MX device tree(ex.: stm32mp157f-mx-dk):
$> ./sdk-infos/generated_build_script-stm32mpx.sh stm32mp1-mx
This command generates a script, sources/*/sdk_compilation-stm32mp1-mx-my-custom-board.sh, on root directory for all source codes from Developer Package.
After the helper script was correctly filled with your configuration (see SDK-infos README for examples and explanation), you can start to use it.
Usage helper script, way of working (here we use a helper script named sdk_compilation-stm32mp-xxx.sh as example)
- To extract the sources codes of components
$> ./sdk_compilation-stm32mp-xxx.sh extract
- To generate boot stage of Cortex-A
$> ./sdk_compilation-stm32mp-xxx.sh compile-for-fip $> ./sdk_compilation-stm32mp-xxx.sh deploy-for-fip
This command generates bl2 and fip binaries for Cortex-A
- To generate binary to flashing via Cortex-A
$> ./sdk_compilation-stm32mp-xxx.sh programmer
This command generates bl2 and fip binaries for flashing on Cortex-A
- To generate kernel and kernel modules:
$> ./sdk_compilation-stm32mp-xxx.sh linux-stm32mp-configure $> ./sdk_compilation-stm32mp-xxx.sh linux-stm32mp-compile $> ./sdk_compilation-stm32mp-xxx.sh linux-stm32mp-deploy
This command generates the kernel image and device tree and exports kernel modules. The Kernel modules can be found stripped and not stripped on deploy directory.
$> ./sdk_compilation-stm32mp-xxx.sh gcnano-driver-stm32mp-compile $> ./sdk_compilation-stm32mp-xxx.sh gcnano-driver-stm32mp-deploy
- To generate m33 firmware for STM32MP2 series' boards for M33-TD flavor :
$> ./sdk_compilation-stm32mp-xxx.sh compile-for-m33fw $> ./sdk_compilation-stm32mp-xxx.sh deploy-for-m33fw
This command generate all the component needed to generate m33fw
2.2. Modifying the Linux kernel[edit | edit source]
Prerequisites:
The partitions related to the Linux kernel are:
- the bootfs partition that contains the Linux kernel U-Boot image (uImage) and device tree
- the rootfs partition that contains the Linux kernel modules
The Linux kernel might be cross-compiled, either in the source code directory, or in a dedicated directory different from the source code directory.
This last method is recommended as it clearly separates the files generated by the cross-compilation from the source code files.
The <Linux kernel installation directory>/README.HOW_TO.txt.<board flavor>[1] helper file gives instructions to:
☐ configure the Linux kernel (applying the ST fragments)
☐ cross-compile the Linux kernel
☐ deploy the Linux kernel (that is, update the software on board)
You can also prefer using the SDK-infos script to easliy manage the above steps.
You can refer to the following simple examples:
- Modification of the kernel configuration
- Modification of the device tree
- Modification of a built-in device driver
- Modification of an external in-tree module
- Adding an external out-of-tree Linux kernel module
2.3. Adding Linux user space applications[edit | edit source]
Prerequisites:
- the SDK is installed
- the SDK is started up
Once a suitable cross-toolchain (OpenSTLinux SDK) is installed, it is easy to develop a project outside of the OpenEmbedded build system.
There are different ways to use the SDK toolchain directly, among which Makefile and Autotools.
Whatever the method, it relies on:
- the sysroot that is associated with the cross-toolchain, and that contains the header files and libraries needed for generating binaries (see target sysroot)
- the environment variables created by the SDK environment setup script (see SDK startup)
You can also prefer using the SDK-infos script to easliy manage the above steps.
You can refer to the following simple example:
2.4. Modifying the U-Boot[edit | edit source]
Prerequisites:
As explained in the boot chain overview, the trusted boot chain is the default solution delivered by STMicroelectronics. Within this scope, the partition related to the U-Boot is the ssbl one that contains the U-Boot and its device tree blob.
The <U-Boot installation directory>/README.HOW_TO.txt.<board flavor>[1] helper file gives instructions to:
☐ cross-compile the U-Boot
☐ deploy the U-Boot (that is, update the software on board)
You can also prefer using the SDK-infos script to easliy manage the above steps.
You can refer to the following simple example:
2.5. Modifying the TF-A[edit | edit source]
Prerequisites:
As explained in the boot chain overview, the trusted boot chain is the default solution delivered by STMicroelectronics. Within this scope, the partition related to the TF-A is the fsbl one.
The <TF-A installation directory>/README.HOW_TO.txt.<board flavor>[1] helper file gives instructions to:
☐ cross-compile the TF-A
☐ deploy the TF-A (that is, update the software on board)
You can also prefer using the SDK-infos script to easliy manage the above steps.
You can refer to the following simple example:
2.6. Modifying the OP-TEE[edit | edit source]
Prerequisites:
As explained in the boot chain overview, the trusted boot chain is the default solution delivered by STMicroelectronics. Within this scope, the partition related to the OP-TEE is the fsbl one.
The <OP-TEE installation directory>/README.HOW_TO.txt.<board flavor>[1] helper file gives instructions to:
☐ cross-compile the OP-TEE
☐ deploy the OP-TEE (that is, update the software on board)
You can also prefer using the SDK-infos script to easliy manage the above steps.
You can refer to the following simple example:
2.7. Modifying the TF-M[edit | edit source]
Prerequisites:
The <TF-M installation directory>/README.HOW_TO.txt.stm32mp2-m33td helper file gives instructions to:
☐ cross-compile the TF-M
☐ deploy the TF-M (that is, update the software on board)
You can also prefer using the SDK-infos script to easliy manage the above steps.
You can refer to the following simple example:
2.8. Modifying the m33tdprojects Starter[edit | edit source]
Prerequisites:
The <m33tdprojects Starter installation directory>/README.HOW_TO.txt.stm32mp2-m33td helper file gives instructions to:
☐ cross-compile the m33tdprojects Starter
☐ deploy the m33tdprojects Starter (that is, update the software on board)
You can also prefer using the SDK-infos script to easliy manage the above steps.
You can refer to the following simple example:
3. References[edit | edit source]
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 