Last edited one year ago

STM32MP1 Distribution Package

Applicable for STM32MP13x lines, STM32MP15x lines

This article describes how to get and use the Distribution Package of the STM32MPU Embedded Software for any development platform of the STM32MP1 family (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:

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 the OpenSTLinux distribution (development on Arm Cortex-A processor), 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 the STM32Cube MPU Package (development on Arm Cortex-M processor for STM32MP15x lines More info.png only), all pieces of software in source code: BSP, HAL, middlewares and applications
Info white.png Information
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)
  • 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)


Components of the Distribution Package

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:

3. Checking the prerequisites[edit source]

3.1. Knowledges[edit source]

The STM32MP1 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.

Development setup for Developer and Distribution Packages


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 STM32MP1 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 STM32MP1 OpenSTLinux distribution: openstlinux-5.15-yocto-kirkstone-mp1-v22.11.23


Warning DB.png Important
Yocto is using absolute directory path to give names to intermediate files. If the path is too long, Yocto build fails because file names exceed the maximum size supported by the file system. In that case, installation directory path should be renamed to reduce the overall absolute path name.
STM32MP1 Distribution Package OpenSTLinux distribution - STM32MP1-Ecosystem-4.1.0 release
Installation
 cd <working directory path>/Distribution-Package
  • Initialize repo in the current directory (More details on 'repo init' here).
 repo init -u https://github.com/STMicroelectronics/oe-manifest.git -b refs/tags/openstlinux-5.15-yocto-kirkstone-mp1-v22.11.23

Note: "ERROR 404" may appear during "repo init" command without any impact on the process

  • Synchronize the local project directories with the remote repositories specified in the manifest (more details on 'repo sync' here)
 repo sync


Note: Distribution package needs around 140MB to be installed (and around 25GB once distribution package is compiled).

Release note

Details about the content of this software package are available in the associated STM32 MPU ecosystem release note.

Archive box.png If interested in previous releases, go through the archives of the 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-qt5                         QT5 layer for 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
│    │   │   │   ├── drivers              Recipes for Vivante GCNANO GPU kernel drivers
│    │   │   │   ├── trusted-firmware-a   Recipes for TF-A
│    │   │   │   └── u-boot               Recipes for U-Boot
│    │   │   ├── recipes-extended
│    │   │   │   ├── linux-examples       Recipes for Linux examples for STM32 MPU devices
│    │   │   │   ├── m4coredump           Recipes for script to manage coredump of cortexM4 (for STM32MP15x lines More info.png lines)
│    │   │   │   ├── m4projects           Recipes for firmware examples for Cortex M4 (for STM32MP15x lines More info.png lines)
│    │   │   │   └── stm32mp-g0           Recipes for G0 USB firmware (for STM32MP13x lines More info.png lines)
│    │   │   ├── 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 STM32MP1 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|...>", 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]

Warning white.png Warning
The environment setup script must have been run

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

Info white.png Information
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:

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 More info.png.

Refer to Distribution Package for STM32CubeMP1 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"
Info white.png Information
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
Info white.png Information
"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)

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

Info white.png Information
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.6-stm32mp-r2-r0                     TF-A software package (source code, patches, makefile, helper file...)
│   │   │   │         └── u-boot-stm32mp-v2021.10-stm32mp-r2-r0        U-Boot software package (source code, patches, makefile, helper file...)
│   │   │   │         ├── linux-stm32mp-5.15.67-stm32mp-r2-r0             Linux kernel software package (source code, patches, helper file...)
│   │   │   │         └── optee-os-stm32mp-3.16.0-stm32mp-r2-r0         U-Boot software package (source code, patches, makefile, helper file...)
│   │   │   └── [...]
│   │   └── [...]
│   └── [...]
└── [...]
  • Optionally, compress the different "source code" directories to get the Developer Package software packages
Info white.png Information
Remember that the SDK items can only be built for 64-bit architecture host PCs

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.

Info white.png Information
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
Links to the commands
Essential commands of the STM32MP157x-EV1 Evaluation board Starter Package
Essential commands of the STM32MP157x-DKx Discovery kit Starter Package
Essential commands of the STM32MP135x-DK Discovery kit Starter Package
Install the STM32MP1 OpenSTLinux distribution
Run the OpenEmbedded environment setup script
Build the st-image-weston image
Flash the image on the microSD card of the STM32MP157x-EV1 Evaluation board
Flash the image on the microSD card of the STM32MP157x-DKx Discovery kit
Flash the image on the microSD card of the STM32MP135x-DK Discovery kit
Develop with the OpenEmbedded distribution (devtool)
Integrate your STM32Cube MPU Package development in the distribution

14. References[edit source]