Skip to main content
Emmanuel COMBETTE DE RYMON
Emmanuel COMBETTE DE RYMON
ST Employee
September 14, 2021

FAQ: Updating OpenSTLinux

  • October 14, 2026 at 3:38 PM
  • 0 replies
  • 10371 views

Purpose

 

Guidelines that may assist you in your decision-making process

  • What is an OpenSTLinux release?
  • Should we move to the next version of OpenSTLinux

General information about OpenSTLinux release

  • Information on firmware update and System recovery mechanisms
  • How to monitor CVE patches

 

1. OpenSTLinux release and ST flow

 

OpenSTLinux release is a set of software components called the board support package (BSP). It includes the boot chain components, the Linux kernel, the root file systems, and a collection of user-space applications from the Yocto Project. It is part of the ecosystem delivery, which also includes tools and extra firmware.

The OpenSTLinux release flow follows Yocto Project long-term support (LTS) deliveries.

The Yocto Project delivers a new version each year: https://wiki.yoctoproject.org/wiki/Releases

The Yocto Project delivers two kernel versions:

  • An LTS kernel version is delivered every two years, and the Yocto Project provides maintenance for two years.
  • A non-LTS kernel version is delivered every two years, and the Yocto Project provides maintenance for seven months.

Yocto Project LTS versions are based on the LTS kernel version.

Each year, STMicroelectronics delivers a new major OpenSTLinux x.0 release based on a Yocto Project long-term support (LTS) version. Based on the same Yocto Project release, two subsequent releases follow: OpenSTLinux x.1.1 after eight months and OpenSTLinux x.2.0 eight months later. This cycle lasts 1.5 years. Each release has a dedicated wiki page.

STMicroelectronics then delivers minor x.2.z releases on GitHub for 2.5 years without a dedicated wiki page.

STMicroelectronics might then deliver releases for one additional year in the event of a vulnerability.

The table below provides the version history of the different releases and their major software component versions: Wiki archives - stm32mpu

For the content of the OpenSTLinux release, see the release note below: https://wiki.st.com/stm32mpu/wiki/STM32_MPU_OpenSTLinux_release_note

For changes in the release, see the release notes: https://wiki.st.com/stm32mpu/wiki/STM32_MPU_OpenSTLinux_release_note#Release_changes_notification

Minor deliveries are available on GitHub:

STMicroelectronics/arm-trusted-firmware: Arm trusted firmware
STMicroelectronics/u-boot: "Das U-Boot" source tree
STMicroelectronics/linux: Linux kernel source tree
STMicroelectronics/optee_os: Trusted side of the TEE (github.com)

To rebuild the latest OpenSTLinux board support package (BSP) source code on a Linux machine, see STM32MPUs-LinuxMachine-SDK-Setup

For an overview of the features of STM32MPU ecosystem release, see OpenSTLinux ecosystem release v6.X


2. ST’s responsibility

 

STMicroelectronics is responsible for the board support package (BSP) components and provides delivery support for five years: 1.5 years for new features, 2.5 years for corrections, and 1 year for vulnerabilities.

Userland components are provided as examples.

For security Common Vulnerabilities and Exposures (CVE) patches for the components, the OpenSTLinux release includes the patches that are available when the release is issued. It does not consolidate any patches after the release. This task is the customer's responsibility or can be handled by an ST partner such as TimeSys.

 

3. Mixing the OpenSTLinux components

 

An OpenSTLinux BSP release is a set of components: TF-A, U-Boot, OP-TEE, and the Linux kernel.

The Linux kernel and U-Boot depend on OP-TEE and TF-A services, so the matched versions in the delivery must be used. The versions are described in the release notes.

Do not mix components from different releases.


4. Move to the next version of OpenSTLinux

Consider the following questions below when you want to update to a new release:

4.1 Is updating to a new release necessary?

Moving to a new major release on the customer side can require significant effort. The update must be evaluated and planned. The product device tree of each software component in the OpenSTLinux board support package (BSP) might need to be adapted again.

4.2 Is a version update really necessary for the product?

It depends on how different the board design is from an STMicroelectronics reference board. Also consider the differences within a given OpenSTLinux release, such as board support package (BSP) configuration differences and Yocto updates from a previous release.

4.3 If the product is close to production with OpenSTLinux X.0

It is recommended to stay on the same version, x.y, and, if possible, use the latest x.y release. Do not switch to the next OpenSTLinux release, x+1.y, unless there is a clear reason.

4.4 If the OpenSTLinux version is updated

Release x.1 is more mature than release x.0 because it includes about six months of additional experience. It is better to switch directly from version x.1 to version x+1.1 than from version x.0.

4.5 If the board is in the bring-up phase

If the board is in the bring-up phase, it may be easier to use a previous, more mature release.
For example, use x.1 instead of x+1.0 for the bring-up phase unless there are valid reasons to use x+1.0.

The following article is recommended for bring-up: 

FAQ: How to bring up STM32MPx | Community

 

5. Firmware update & system recovery mechanisms

 

  • About Firmware update:

    OpenSTLinux offers the firmware over-the-air (OTA) update feature for the boot chain except for TF-A BL2 (FSBL).

    The fip-boot partition, which contains BL31 for STM32MP2, OP-TEE, and U-Boot, can be updated. The firmware update is based on A/B partitions. For this the flash mapping contains the “metadata” partition for the controls of the switch mechanism between partition A (boot chain A) and partition B (boot chain B), see STM32 MPU flash mapping - stm32mpu

    During the firmware update phase only, the system checks that the new boot chain boots correctly before it switches to the new partition. Otherwise, the boot remains on the previous boot chain.

    Information is available at https://wiki.st.com/stm32mpu/wiki/Secure_Firmware_Update.

  • About System recovery:
    The System recovery feature that boots the kernel from initramfs in case of boot the kernel  fails to boot from flash partition is not present by default in OpenSTlinux release
     

As already mentioned, partitions of the same bootchain must be aligned on the same release: TF-A, U-boot, OP-TEE, and kernel.

A partner foundries.io implements firmware update with STM32MP series
Incremental Kernel & Docker App OTA Updates | Foundries.io


6. Security vulnerability incidents 


Customer can report vulnerability on ST hardware or software ST provide security advisories and security notes on each product page (hardware or software) and also on our Product Security Incident Response Team (PSIRT) page.

Each component release has a list of CVE. STMicroelectronics does not consolidate these lists but they are public by the software providers. Third-party providers such as TimeSys can consolidate patches.

The CVE monitoring process is done by the U-boot, TF-A and OP-TEE communities, they are described here:

TF-A:

OP-TEE:

For products using OP-TEE your company can register as a "Trusted Stakeholder" to be aware on vulnerabilities and corrections before they are published.
https://developer.trustedfirmware.org/w/collaboration/security_center/trusted_stakeholder_registration/

See the link below for a list of published vulnerabilities:
https://github.com/OP-TEE/optee_os/security/advisories?state=published


U-boot: (Example for version 2020.01)

Linux kernel: The CVE list is available with an example for kernel 5.15

 

    This topic has been closed for replies.
    Terms & ConditionsAccessibility statement