On this page, learn how to create your own STM32MPU Expansion package to extend the limit of the ecosystem.
1. Design of a STM32MPU Expansion for OpenSTLinux Distribution Package[edit source]
A STM32MPU Expansion package for OpenSTLinux Yocto distribution is a solution proposed to extend a Distribution Package by providing new features, examples or demonstrations.
Three possible profile types are defined to covered different user needs and following the required changes on the OpenSTLinux distribution:
- OpenSTLinux tools add-on: in case of making changes only at Linux user space level, without any changes on boot chain or Linux OS.
- OpenSTLinux embedded software add-ons: in case of modifying Linux kernel part (configuration, device tree update), or/and adding user space application(s)/framework(s) needed to demonstrate Cortex-A processor functionality
- Coprocessor and OpenSTLinux embedded software add-ons: in case of profile type 2 and/or need to modify STM32CubeMPU part and/or to include new firmware source code example to demonstrate Cortex-M coprocessor functionality
2. Check for OpenSTLinux compability version[edit source]
For ecosystem release ≥ v3.1.0 :
In order to ensure the adherence with a given OpenSTLinux version, the dependency is managed with a dedicated ST_OSTL_COMPATIBILITY_VERSION_<layer_name> variable to set in the I-PACK Yocto meta layer (layer.conf file).
This information is verified at compilation phase.
To get the version to set, please refer to the variable value given in meta-st-openstlinux/conf/layer.conf , for example:
ST_OSTL_COMPATIBILITY_VERSION_st-openstlinux = "3.1"
For ecosystem release ≤ v3.0.0 :
Typo issue was present: ST_OSTL_COMPATIBILTY_VERSION instead of ST_OSTL_COMPATIBILITY_VERSION
In order to ensure the adherence with a given OpenSTLinux version, the dependency is managed with a dedicated ST_OSTL_COMPATIBILTY_VERSION_<layer_name> variable to set in the I-PACK Yocto meta layer (layer.conf file).
This information is verified at compilation phase.
To get the version to set, please refer to the variable value given in meta-st-openstlinux/conf/layer.conf , for example:
ST_OSTL_COMPATIBILTY_VERSION_st-openstlinux = "3.0"
3. STM32MPU Expansion cases[edit source]
3.1. OpenSTLinux tools add-on[edit source]
This profile type covers the case when only changes/additions are done at Linux user space level for application(s), tool(s) or script(s) on the root file system.
Two possible approaches:
- Add a Standard Yocto layer on the OpenSTLinux distribution: please refer to existing skeleton example[1] in yocto project
- Deploy a Debian package on the target: in case all dependencies are already managed on Embedded software on the target, this is possible to install the new application(s) by using a standard Debian package
3.2. OpenSTLinux embedded software add-ons[edit source]
This profile type covers previous one and is recommended when some additional changes are required at Linux kernel level (configuration and/or device tree update), and/or adding user space application(s)/framework(s) needed to demonstrate Cortex-A processor functionalities.
For this case, the OpenSTLinux distribution must be updated, and the proposed solution is to add a new add-on meta layer to provide the services described below. A meta layer template is proposed as reference to help modifying BSP components: meta-st-stm32mp-addons[2].
Otherwise, if only user space applications and image need to be updated, please refer to existing skeleton example[1] in Yocto project for a standard Yocto layer.
3.2.1. New image creation with additional Linux user space packages[edit source]
Refer to the How_to_create_your_own_image wiki page.
As example, please have a look the the X-LINUX-AI expansion package image recipe: https://github.com/STMicroelectronics/meta-st-stm32mpu-ai/blob/master/recipes-st/images/st-image-ai.bb
3.2.2. TF-A, OP-TEE, U-Boot, Kernel device tree(s) update[edit source]
Two possible approaches, which depend of the way the top device tree source file is written for the given reference board:
- The dts file contain the complete device tree settings and is generated by using CubeMx (see STM32CubeMX_generated_device_tree)
- A new device tree source file (.dts) inherit from an existing DT file of a ST board and is used to modify/add DT node Overload the device tree (i.e. minor changes compared to existing boards)
For both approaches, the way to declare it in the I-Pack meta layer is the same, and is done in the machine file (conf/machine directory). For example please see conf/machine/stm32mp13-mx.conf (STM32MP13x lines ) or conf/machine/stm32mp15-mx.conf (STM32MP15x lines ).
- Force the new device tree source file usage: ENABLE_CUBEMX_DTB ?= "1"
- Define the dtb binary name to be generated, which is the same as the dts file you want to use: CUBEMX_DTB = "<your_dtb_file_name>"
- Define the path for the device tree files: CUBEMX_PROJECT = "'<your_dt_file_path>"
Ensure the corresponding device tree source files that have to be taken into account must be present in the path given by variable CUBEMX_PROJECT previously defined.
Then, as the examples provided in meta-st-stm32mp-addons[2], this is possible for each BSP components to define the device tree source file to be used by an update of the corresponding recipes.
Component | Yocto recipe append example for BSP components |
---|---|
TF-A | tf-a-stm32mp_%.bbappend |
OP-TEE | optee-os-stm32mp_%.bbappend |
U-Boot | u-boot-stm32mp_%.bbappend |
Linux Kernel | linux-stm32mp_%.bbappend |
3.2.3. Linux kernel configuration change[edit source]
Two possible approaches:
- Make defconfig changes by using a configuration fragment file (recommended)
- Provide a full defconfig file
3.2.3.1. Change defconfig with a configuration fragment file[edit source]
A simple way to update the Linux kernel configuration is to use a fragment file. You can refer to the Yocto Project web article Creating Configuration Fragments for information.
The config fragment file must be added in the path meta-st-stm32mp-addons/recipes-kernel/linux/linux-stm32mp/<config_fragment_file_name>.
The linux-stm32mp recipe file must be appended in order to update the build setup. It is done through the file meta-st-stm32mp-addons/recipes-kernel/linux/linux-stm32mp_%.bbappend.
In this file, the new config fragment file must be added to the variable KERNEL_CONFIG_FRAGMENTS and listed in the SRC_URI variable as given below:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI += "file://<config_fragment_file_name>" KERNEL_CONFIG_FRAGMENTS += "<config_fragment_file_name>"
3.2.3.2. Use new full defconfig file[edit source]
This is also possible to provide a full defconfig file for the Linux kernel configuration building.
For creating a defconfig file, please refer to the Yocto Project web article Creating a defconfig File.
The file must be present in the path meta-st-stm32mp-addons/recipes-kernel/linux/linux-stm32mp/<defconfig_file_name>.
The linux-stm32mp recipe file must be appended in order to update the build setup. It is done through the file meta-st-stm32mp-addons/recipes-kernel/linux/linux-stm32mp_%.bbappend.
In this file, the variable KERNEL_DEFCONFIG has to be cleaned, the new variable KERNEL_EXTERNAL_DEFCONFIG must be defined and the path of the <defconfig_file_name> listed in the SRC_URI variable as given below:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI += "file://<defconfig_file_name>" KERNEL_DEFCONFIG = "" KERNEL_EXTERNAL_DEFCONFIG = "<defconfig_file_name>"
3.2.4. Addition of source code / binary files for new applications[edit source]
Refer to How_to_add_a_customer_application wiki article.
Two other wiki pages are also proposed to help for meta-st-stm32mp-addons usage:
3.3. Coprocessor and OpenSTLinux embedded software add-ons[edit source]
Coming soon |
This profile type inherit from OpenSTLinux embedded software add-ons and is recommended when some changes are required at STM32CubeMPU part and/or to include new firmware source code example to demonstrate Cortex-M coprocessor functionality (including hardware resources reallocations).
4. I-Pack expansion package example[edit source]
X-LINUX-AI_OpenSTLinux_Expansion_Package
5. References[edit source]