Changes notification

1. Article purpose[edit | edit source]

The article aims to help rebase an STM32 MPU project on a new ecosystem release by focusing on the impacts of the main changes.

2. Scope of this article[edit | edit source]

This article provides some details for the main changes between ecosystem release v6.2.0 and new ecosystem release v6.2.1 . The aim is to help you to migrate your project.

All Information about the features delivered in the new release is available in the OpenSTLinux release note.

Important

In case of upgrade from OpenSTLinux ecosystem release v6.0.0, check first the previous release change notification available in this wiki, dedicated to the v6.y.z ecosystem releases:

3. Impacted domains[edit | edit source]

3.1. Yocto build environment for Distribution Package[edit | edit source]

Remove usage specific image for each partitions
Add image class to split rootfs image on several partitions: ST SPLIT PARTITIONS (see below paragraph for details)
IMAGE: all partitions needed by the flashlayout are provided by the class stsplitpartitions with partitions split's of default rootfs image.
"STM32CubeMP1" and "STM32CubeMP2" directories renamed (not the recipe name)
STM32CubeMP2: management of firmware ready to use via m33fw-stm32mp2 (default STM32CubeMP2 recipe provide only binaries that can be associated to others binary blob)

3.1.1. ST SPLIT Partitions detailed information[edit | edit source]

New stsplitpartitions class allows to split an unique image requested on several partitions/pieces like WIC does (for e.MMC storage).

Main advantage of creating a unique image is to ensure that all package dependencies are properly managed, and then you do not need to think about the destination of each files for a package which required to be split in different partitions.

In this OpenSTLinux release, the unique built image is rootfs.

The class support only few output format:

extx (ext2 ext2.gz ext2.bz2 ext3 ext3.gz ext3.bz2 ext4 ext4.gz ext4.bz2)
jffs2
tar (tar tar.bz2 tar.xz)
vfat
squashfs (squashfs squashfs-xz squashfs-zst)
multiubi for nand storage

To enable this ST image split mechanism, the variable PARTITIONS_IMAGES must be populated with parameters:

List of partitions to create and their definition
- ex. PARTITIONS_IMAGES = "bootfs vendorfs rootfs userfs"
Definition of each partition:
- Image name, ex: ${IMAGE_BASENAME}
- Label of the partition, ex.: bootfs
- Mount point of the partition, ex: /boot
- Size of partition (on KB), ex: 65535 (64MB)
- Type of the partition for flasher
  - ESP for efi boot partition
  - System for boot partition (bootfs partition)
  - FileSystem for other linux partitions (vendorfs, userfs, rootfs,....)
- Number of copy (used for tsv creation)
- List of file systems not supported by this partition (ex. if you would like the partition not to be available on vfat while you would like to have for bootfs partition only).

Here is an example to illustrate:

PARTITIONS_IMAGES = "bootfs vendorfs rootfs userfs
PARTITIONS_IMAGES[bootfs] ?= "${IMAGE_BASENAME},bootfs,/boot,65536,System,0"
PARTITIONS_IMAGES[userfs] ?= "${IMAGE_BASENAME},userfsfs,/usr/local,131072,FileSystem,0"

The definition of bootfs, rootfs, vendorfs, userfs is defined here

Support of annex image

We propose also the possibility to generate a custom annex image, not part of the main unique image and to put on a specific partitions.

On meta-st-stm32mp/recipes-st/images/ , we provide some example of custom annex image that can replace a split image on specific partition.

To enable the build of this custom annex image, STM32MP_IMAGE_DEPENDS variable must be defined:

ex.: STM32MP_IMAGE_DEPENDS = "st-image-bootfs"

Then, to use the custom annex image on the TSV , for flashloading the target, we need to force the partition image name:

STM32MP_BOOTFS_IMAGE = "st-image-bootfs-${DISTRO}-${MACHINE}.bootfs.vfat"
#STM32MP_USERFS_IMAGE = "my-image-userfs-${DISTRO}-${MACHINE}.userfs"
#STM32MP_VENDORFS_IMAGE = "my-image-vendorfs-${DISTRO}-${MACHINE}.vendorfs"

Note: lines in comment are other example for some custom annex images.

3.2. Hardware configuration[edit | edit source]

Check the device tree files for the STMP32 MPU board. For that, you compare both versions of the following components:

Information

This is possible with git diff command to get delta between two branches in the same repository.
Example with STLINUX GitHub repository and for all STM32MP1 device tree files:

git diff v6.6-stm32mp-r3.1 v6.6-stm32mp-r3 -- arch/arm/boot/dts/stm32mp1*

Linux^® kernel: between Linux kernel v6.6-stm32mp-r3.1 (LTS v6.6.129) and previous Linux kernel v6.6-stm32mp-r3 (LTS v6.6.116)

U-Boot: between U-Boot v2023.10-stm32mp-r3.1 and previous U-Boot v2023.10-stm32mp-r3
- Alignment with Linux^® kernel device tree

OP-TEE: between OP-TEE 4.0.0-stm32mp-r3.1 and previous OP-TEE 4.0.0-stm32mp-r3
- Alignment with Linux^® kernel device tree

TF-A: between TF-A v2.10-stm32mp-r3.1 (LTS v2.10.24) and previous TF-A v2.10-stm32mp-r3 (LTS v2.10.24)
- Alignment with Linux^® kernel device tree

External DT: between External DT v6-stm32mp-r3.1 and previous External DT v6-stm32mp-r3
- Alignment with Linux^® kernel device tree
- Update directory tree by supporting STM32MP1 series and introducing M33-TD flavor

3.3. System configuration[edit | edit source]

Directory tree changed in External DT component
The configuration of OP-TEE profile is now centralized via the usage of boot scheme:
- BOOTSCHEME_LABELS += "opteemin" for system_services
- BOOTSCHEME_LABELS += "optee" for secure_and_system_services

3.4. Boot stages[edit | edit source]

None

3.5. Security[edit | edit source]

None

3.6. User space and applications[edit | edit source]

None