This article describes how to get and use the Distribution Package of the STM32MPU Embedded Software for any development platform of the STM32MPU family (STM32MP25 boards, STM32MP15 boards and STM32MP13 boards), in order to modify or add pieces of software, and to create the right Linux distribution, for the targeted product.
It lists some prerequisites in terms of knowledges and development environment, and gives the step-by-step approach to download and install the STM32MPU Embedded Software packages for this Package.
Finally, it proposes some guidelines to upgrade (add, remove, configure, improve...) any piece of software.
1. Distribution Package content[edit source]
If you are not yet familiar with the STM32MPU Embedded Software distribution and its Packages, please read the following articles:
- Which STM32MPU Embedded Software Package better suits your needs (and especially the Distribution Package chapter)
- STM32MPU Embedded Software distribution
If you are already familiar with the Distribution Package for the STM32MPU Embedded Software distribution, the fast links to essential commands might interest you.
To sum up, this Distribution Package provides:
- a build framework based on OpenEmbedded (aka distribution builder)
- for development on Arm Cortex-A processor:
- the OpenSTLinux distribution containing all pieces of software in source code: the BSP (Linux kernel, U-Boot, TF-A, OP-TEE), and the application frameworks (Wayland-Weston, GStreamer, ALSA...)
- for development on Arm Cortex-M processor (STM32MP15x lines
and STM32MP25x lines
):
- the STM32Cube MPU Package containing all pieces of software in source code: BSP, HAL, middlewares and applications
- the Trusted Firmware Cortex-M secure OS running on the Arm® Cortex®-M in secure mode which provides local secure services to STM32Cube MPU Package.
![]() |
Note that, within the Distribution Package, the STM32CubeMP1 Package is integrated in the OpenSTLinux distribution through the specific recipe for Cube projects (recipes-extended/m4projects/m4projects-stm32mp1.bb) of the STMicroelectronics layer for the STM32 MPU devices (meta-st-stm32mp) |
![]() |
Note that, within the Distribution Package, the STM32CubeMP25 Package is integrated in the OpenSTLinux distribution through the specific recipe for Cube projects (recipes-extended/m33projects/m33projects-stm32mp2.bb) of the STMicroelectronics layer for the STM32 MPU devices (meta-st-stm32mp) |
- a toolset to tune the system for your needs, and to handle the built image (e.g. STM32CubeProgrammer to install the built image on the board)
2. Distribution Package step-by-step overview[edit source]
The steps to get the STM32MPU Embedded Software packages ready for your developments, are:
☐ Checking the prerequisites
☐ Installing the Starter Package for your board
☐ Installing the OpenSTLinux distribution
☐ Building the OpenSTLinux distribution
☐ Flashing the built image
☐ Checking the boot sequence
Once these steps are achieved, you are able to:
- modify software running on Arm Cortex-A
- modify software running on Arm Cortex-M Only supported for STM32MP15x lines
and STM32MP25x lines
- create your own Linux distribution
- generate your own Starter and Developer Packages
3. Checking the prerequisites[edit source]
3.1. Knowledges[edit source]
The STM32MPU Distribution Package aims at creating a Linux distribution for the targeted product: solid knowledges about Linux are recommended to make the most of this Package.
The OpenSTLinux distribution is a Linux distribution based on the OpenEmbedded (/Yocto Project) build framework for embedded Linux: a short introduction about OpenEmbedded and links towards the standard documentation and trainings are available in the OpenEmbedded article.
Having a look at the STM32MPU Embedded Software architecture overview is also highly recommended.
3.2. Development setup[edit source]
The recommended setup for the development PC (host) is specified in the following article: PC prerequisites.
Whatever the development platform (board) and development PC (host) used, the range of possible development setups is illustrated by the picture below.
The following components are mandatory:
- Host PC for cross-compilation and cross-debugging, installed as specified above
- Board assembled and configured as specified in the associated Starter Package article
- Mass storage device (for example, microSD card) to load and update the software images (binaries)
The following components are optional, but recommended:
- A serial link between the host PC (through Terminal program) and the board for traces (even early boot traces), and access to the board from the remote PC (command lines)
- An Ethernet link between the host PC and the board for cross-development and cross-debugging through a local network. This is an alternative or a complement to the serial (or USB) link
- A display connected to the board, depending on the technologies available on the board: DSI LCD display, HDMI monitor (or TV) and so on
- A mouse and a keyboard connected through USB ports
Additional optional components can be added by means of the connectivity capabilities of the board: cameras, displays, JTAG, sensors, actuators, and much more.
4. Installing the Starter Package[edit source]
Before installing and using the Distribution Package, it is essential to get familiar with your board thanks to its Starter Package. All articles relative to Starter Packages are found in Category:Starter Package: find the one that corresponds to your board, and follow the installation instructions (if not yet done), before going further.
In brief, it means that:
- your board boots successfully
- the flashed image comes from the same release of the STM32MPU Embedded Software distribution than the OpenSTLinux distribution that will be downloaded in this article
Thanks to the Starter Package, all Flash partitions are populated.
Then, with the Distribution Package, it is possible to modify or to upgrade any of these partitions independently one from the others.
5. Installing the OpenSTLinux distribution[edit source]
- The STM32MPU OpenSTLinux distribution is delivered through a manifest repository location and a manifest revision.
- The installation relies on the repo command. In case the Repo tool (a Google-built repository management tool that runs on top of git) is not yet installed and configured on the host PC, refer to the PC prerequisites article.
- The OpenSTLinux distribution is massively using open source software (OSS) packages that are downloaded from a variety of open source repositories; so it is required that the IT infrastructure proxies do not forbid such accesses. If some proxy-related issues are suspected, refer to the How to avoid proxy issues article.
- Install the STM32MPU OpenSTLinux distribution: openstlinux-6.1-yocto-mickledore-mpu-v24.06.26
STM32MPU Distribution Package OpenSTLinux distribution - STM32MPU-Ecosystem-5.1.0 release | |
---|---|
Installation |
cd <working directory path>/Distribution-Package
repo init -u https://github.com/STMicroelectronics/oe-manifest.git -b refs/tags/openstlinux-6.1-yocto-mickledore-mpu-v24.06.26 Note: "ERROR 404" may appear during "repo init" command without any impact on the process
repo sync
|
Release note |
Details about the content of this software package are available in the associated STM32 MPU ecosystem release note.
|
- When installed, the OpenSTLinux Distribution Package is available with following tree structure:
Distribution-Package OpenSTLinux distribution ├── layers │ ├── meta-openembedded Collection of layers for the OpenEmbedded-Core universe (OpenEmbedded standard) │ ├── meta-st │ │ ├── meta-st-openstlinux STMicroelectronics layer that contains the frameworks and images settings for the OpenSTLinux distribution │ │ ├── meta-st-stm32mp STMicroelectronics layer that contains the description of the BSP for the STM32 MPU devices │ │ │ ├── recipes-bsp │ │ │ │ ├── alsa Recipes for ALSA control configuration │ │ │ │ ├── ddr-firmware Firmware for DDR PHY on STM32MP │ │ │ │ ├── drivers Recipes for Vivante GCNANO GPU kernel drivers │ │ │ │ ├── fip-stm32mp FIP generation │ │ │ │ ├── trusted-firmware-a Recipes for TF-A │ │ │ │ ├── trusted-firmware-m For STM32MP25x linesonly - Recipes for TF-M │ │ │ │ └── u-boot Recipes for U-Boot │ │ │ ├── recipes-connectivity │ │ │ │ ├── bluetooth Systemd service to suspend/resume correctly bluetooth │ │ │ │ ├── openssl bbappend recipe to add openssl environment setup to SDK │ │ │ ├── recipes-extended │ │ │ │ ├── external-dt Recipes for providing device tree files for STM32 MPU devices outside of BSP components │ │ │ │ ├── linux-examples Recipes for Linux examples for STM32 MPU devices │ │ │ │ ├── libb64 For STM32MP25x lines
only - Library for base64 encoding/decoding data │ │ │ │ ├── m33projects For STM32MP25x lines
only - Recipes for firmware examples for Cortex M33 │ │ │ │ ├── m4coredump For STM32MP15x lines
only - Recipes for script to manage coredump of cortexM4 │ │ │ │ ├── m4projects For STM32MP15x lines
only - Recipes for firmware examples for Cortex M4 │ │ │ │ └── stm32mp-g0 For STM32MP13x lines
only - Recipes for G0 USB firmware │ │ │ ├── recipes-graphics │ │ │ │ ├── gcnano-userland Recipes for Vivante libraries OpenGL ES, OpenVG and EGL (multi backend) │ │ │ │ └── [...] │ │ │ ├── recipes-kernel │ │ │ │ ├── linux Recipes for Linux kernel │ │ │ │ └── linux-firmware Recipes for Linux firmwares (example, Bluetooth firmware) │ │ │ │ └── [...] │ │ │ ├── recipes-security │ │ │ │ ├── optee Recipes for OPTEE │ │ │ ├── recipes-st │ │ │ │ └── images Recipes for the bootfs and userfs partitions binaries │ │ │ │ └── [...] │ │ │ └── [...] │ │ ├── meta-st-stm32mp-addons STMicroelectronics layer that helps managing the STM32CubeMX integration │ │ └── scripts │ │ ├── envsetup.sh Environment setup script for Distribution Package │ │ └── [...] │ └── openembedded-core Core metadata for current versions of OpenEmbedded (standard)
5.1. Initializing the OpenEmbedded build environment[edit source]
The OpenEmbedded environment setup script must be run once in each new working terminal in which you use the BitBake or devtool tools (see later):
DISTRO=openstlinux-weston MACHINE=<machine> source layers/meta-st/scripts/envsetup.sh
The BSP for STM32MPU depends on packages and firmwares which are covered by a software license agreement (SLA). You will be asked to read and to accept this EULA.
Note that:
- The software packages for the Starter Package (image) and for the Developer Package (SDK...) are delivered for one configuration only (DISTRO="openstlinux-weston", MACHINE="<stm32mp13-disco|stm32mp1|stm32mp2|...>", IMAGE="st-image-weston").
- Other values for DISTRO, MACHINE and IMAGE are proposed in OpenSTLinux distribution
Among other things, the environment setup script creates the build directory named build-<distro>-<machine> directory. After the script runs, the current working directory is set to this build directory. Later, when the build completes, it contains all the files created during the build.
The local configuration file (build-<distro>-<machine>/conf/local.conf) contains all local user settings. The layers configuration file (build-<distro>-<machine>/conf/bblayers.conf) tells BitBake what layers must be considered during the build.
openstlinux-[...] OpenSTLinux distribution ├── build-<distro>-<machine> Build directory │ ├── conf │ │ ├── bblayers.conf Local configuration file │ │ ├── local.conf Layers configuration file │ │ └── [...] │ └── workspace ├── layers │ ├── meta-openembedded │ ├── [...]
6. Building the OpenSTLinux distribution[edit source]
The bitbake <image> command is used to build the image. <image> specifies the targeted image, st-image-weston here (Weston image for OpenSTLinux with basic Wayland support).
bitbake st-image-weston
BitBake is a core component of the Yocto Project and is used by the OpenEmbedded build system to build images. This build engine executes shell and Python tasks according to provided metadata stored in recipe (.bb), configuration (.conf), and class (.bbclass) files. The BitBake cheat sheet article introduces some BitBake command-line options, describes shortly the syntax of the recipes (.bb), and gives links towards standard documentation.
Note that:
- The software packages for the Starter Package (image) and for the Developer Package (SDK...) have been built for this st-image-weston image
- Other values for <image> are proposed as examples in OpenSTLinux distribution (take care of the compatibility between the value selected for DISTRO and the value targeted for <image>)
By default, every BitBake task is accomplished in the build directory (see more information about the build directory structure in Yocto Project Documentation[1]).
7. Flashing the built image[edit source]
The build-<distro>-<machine>/tmp-glibc/deploy/images/<machine> directory receives complete file system images.
Build directory structure: images
![]() |
This is an example: the files that you will see in your build directory, might slightly differ |
build-<distro>-<machine>/tmp-glibc/deploy └── images | └── stm32mp1 | ├── flashlayout_st-image-weston Flash layout files (description of the partitions) for the supported flash devices | │ ├── FlashLayout_sdcard_stm32mp157c-dk2-optee.tsv Flash layout file for microSD card and OP-TEE → STM32MP15 Discovery kits | │ ├── FlashLayout_sdcard_stm32mp157c-dk2-trusted.tsv Flash layout file for microSD card and trusted boot chain (recommended setup) → STM32MP15 Discovery kits | │ ├── FlashLayout_sdcard_stm32mp157c-ev1-optee.tsv Flash layout file for microSD card and OP-TEE → STM32MP15 Evaluation boards | │ ├── FlashLayout_sdcard_stm32mp157c-ev1-trusted.tsv Flash layout file for microSD card and trusted boot chain (recommended setup) → STM32MP15 Evaluation boards | │ ├── [...] | │ ├── FlashLayout_sdcard_stm32mp135f-dk-optee.tsv Flash layout file for microSD card and OP-TEE → STM32MP13 Discovery kits | │ └── [...] | ├── fip FIP images to flash pointed by flashlayouts | │ ├── fip-stm32mp157c-dk2-optee.bin | │ ├── fip-stm32mp157c-dk2-trusted.bin | │ ├── fip-stm32mp157f-dk2-optee.bin | │ ├── fip-stm32mp135f-dk-optee.bin | │ └── [...] | ├── scripts | │ └── create_sdcard_from_flashlayout.sh | ├── splash.bin U-Boot splash screen picture (file in BMP format with a .bin extension) for NOR Flash | ├── kernel | │ ├── uImage Linux kernel binary image file (with U-Boot wrapper) for bootfs partition | │ ├── vmlinux Debug symbol file for Linux kernel | │ └── [...] | ├── st-image-bootfs-openstlinux-weston-<machine>.ext4 Binary for bootfs partition | ├── st-image-userfs-openstlinux-weston-<machine>.ext4 Binary for userfs partition | ├── st-image-vendorfs-openstlinux-weston-<machine>.ext4 Binary for vendorfs partition | ├── st-image-weston-openstlinux-weston-<machine>.ext4 Binary for rootfs partition | └── [...] └── [...]
The STM32CubeProgrammer tool is used to flash the STM32MPxx boards with the built image. It's assumed that this tool has been installed through the Starter Package associated with your board.
Depending on the board, several Flash devices (microSD, eMMC...) might be available. The microSD card is considered as the Flash device in the rest of this article.
The procedure to flash your board is explained in the Starter Package article that corresponds to your board (remember that all articles relative to Starter Packages are found in Category:Starter Package):
Once the flashing is terminated, the boot switches must be configured so that the Flash device (e.g. microSD card) on which the image has been flashed, is selected as the boot source:
- Boot switches on the STM32MP135x-DK Discovery kit
- Boot switches on the STM32MP157x-DK Discovery kit
- Boot switches on the STM32MP157x-EV1 Evaluation board
- Boot switches on the STM32MP257x-EV1 Evaluation board
8. Checking the boot sequence[edit source]
You can check the build by executing the same basic commands as the ones described in the Starter Package article for your board: Category:Starter Package.
9. Modifying software running on Arm Cortex-A[edit source]
Now that the OpenSTLinux distribution is installed and built, let's customize it thanks to standard OpenEmbedded methods (e.g. creating a layer) and utilities (e.g. devtool).
9.1. Creating a layer[edit source]
Your software packages developed on top of the OpenSTLinux distribution shall be added in one (or more) custom layer(s). In the same way, your modifications (add-ons, improvements, customizations) in packages that already exist in layers of the OpenSTLinux distribution, shall be appended in custom layer(s), especially to ease the maintenance.
The How to create a new open embedded layer article proposes different ways to create and manage these custom layer(s).
9.2. devtool utility[edit source]
OpenEmbedded is a build framework used to create Linux distributions for embedded devices, and is originally not a development environment. An OpenEmbedded companion utility named devtool aids in developing, building, and testing code that is going to be integrated into an image built using the OpenEmbedded build system.
The OpenEmbedded - devtool article gives an overview of this tool, and introduces the way to add, modify and integrate new application or library in a distribution.
The following article describes same examples as the ones in "How to cross-compile with the Developer Package" but in the Distribution Package context:
9.3. Integrating developments made with the Developer Package[edit source]
To integrate some developments described in previous chapter 9.2 in Yocto build process, we explain here how to:
10. Modifying software running on Arm Cortex-M[edit source]
This chapter is only applicable for STM32MP15x lines and STM32MP25x lines
.
Refer to Distribution Package for STM32CubeMP15 or Distribution Package for STM32CubeMP25 to understand how the STM32Cube MPU package is integrated to the STM32MPU embedded software distribution with Yocto project.
It can be useful if you want to:
- remove the STM32Cube MPU Package from your own distribution
- install your own Cube Cortex-M project for your own distribution
- modify the STM32Cube MPU Package delivered by ST for your own distribution
11. Creating your own Linux distribution[edit source]
First, it is possible to customize your software to fit hardware modification with article: How to create your own machine.
How to create your own distribution is the next step to do if you want to enable some framework (like wayland or x11) and some features (like alsa, nfs, wifi, bluetooth, ipv6, ...).
Then to add some missing userland tools (like libdrm, evtests, iptables, i2c-tools, ...), you can customize some existing images. You have to go to this article: How to create your own image.
12. Generating your own Starter and Developer Packages[edit source]
Now that either the OpenSTLinux distribution has been modified, or a new distribution has been created, it might be time to provide the developers with new Starter and Developer Packages, that are enriched with the additional or improved features of the new distribution.
Prerequisites:
- It is assumed here that your recipes have been updated with patches that reflect changes you make to the source files, thanks to the devtool update-recipe command
- So, either original recipes (.bb) have been modified with your changes, or recipes of your own layers (How to create a new open embedded layer) have been modified with your changes, so that the custom recipes (.bbappend) and your patches are clearly isolated from the original ones (recommended method to ease the maintenance)
- Run the environment setup script; select, for DISTRO and MACHINE, the values for which you want to generate the Starter and Developer Packages (see OpenSTLinux distribution for all possible values)
DISTRO=<distro> MACHINE=<machine> source layers/meta-st/scripts/envsetup.sh
Example:
DISTRO=openstlinux-weston MACHINE=stm32mp1 source layers/meta-st/scripts/envsetup.sh
- Modify the build-<distro>-<machine>/conf/local.conf file to enable archiver for recipes that are configured to use it; the objective is to generate the "source code" software packages for the Developer Package (Linux kernel, gcnano-driver, U-Boot, TF-A and OP-TEE OS)
ST_ARCHIVER_ENABLE = "1"
![]() |
Take care to disable this configuration when you are not in the process of generating your own Starter and Developer Packages |
- Build the image to ensure that your last developments integrated in the distribution are reflected in the image, and to generate the "source code" software packages for the Developer Package; select, for <image>, the value for which you want to generate the Starter and Developer Packages (see OpenSTLinux distribution for all possible values)
bitbake <image> --runall=deploy_archives
Example:
bitbake st-image-weston --runall=deploy_archives
![]() |
"deploy_archives" parameter is not normally required but without it the archives are not fully generated in some cases (so better add it by default) |
- The image (binaries) for the Starter Package are available in the build-<DISTRO>-<MACHINE>/tmp-glibc/deploy/images/<machine> directory
Note that the structure of this images/<machine> directory is obviously similar to the directory structure of the Starter Package.
- The "source code" for the Developer Package software packages (Linux kernel, gcnano-driver, U-Boot, TF-A and OP-TEE OS) are available in the build-<distro>-<machine>/tmp-glibc/deploy/sources/arm-ostl-linux-gnueabi directory
Note that the structure of this sources/arm-ostl-linux-gnueabi directory is obviously similar to the directory structure of the Developer Package for TF-A, OP-TEE OS, Linux kernel, gcnano-driver and U-Boot.
Build directory structure: sources
![]() |
This is an example: the files that you will see in your build directory, might slightly differ |
build-<distro>-<machine> Build directory ├── tmp-glibc │ │ ├── deploy │ │ │ ├── sources │ │ │ │ └── arm-ostl-linux-gnueabi │ │ │ │ ├── tf-a-stm32mp-v2.8.15-stm32mp-r2-r0 TF-A software package (source code, patches, makefile, helper file...) │ │ │ │ ├── u-boot-stm32mp-v2022.10-stm32mp-r2-r0 U-Boot software package (source code, patches, makefile, helper file...) │ │ │ │ ├── linux-stm32mp-6.1.82-stm32mp-r2-r0 Linux kernel software package (source code, patches, helper file...) │ │ │ │ └── optee-os-stm32mp-3.19.0-stm32mp-r2-r0/ OP-TEE software package (source code, patches, makefile, helper file...) │ │ │ └── [...] │ │ └── [...] │ └── [...] └── [...]
- Optionally, compress the different "source code" directories to get the Developer Package software packages
- Generate the last element namely the new software development kit (SDK) for the Developer Package with the How to create an SDK for OpenSTLinux distribution article
![]() |
The SDK items can only be built for 64-bit architecture host PCs (x86_64 or arm64) |
13. Fast links to essential commands[edit source]
If you are already familiar with the Distribution Package for the STM32MPU Embedded Software distribution, fast links to the essential commands are listed below.
![]() |
With the links below, you will be redirected to other articles; use the back button of your browser to come back to these fast links |
14. References[edit source]