Skip to main content
R
retroll
Graduate
October 16, 2023
Solved

Double partitions to implement A/B update mechanism

  • October 16, 2023
  • 2 replies
  • 7210 views

Hello, i'm currently working on the stm32mp135f-dk with the kirkstone yocto version for layers provided by st. I'm trying to double all fs partitions (rootfs bootfs and userfs) to implement a software update mechanism with an active set of partitions and another one that will be used after being updated. My Flashlayout.tsv file generated by bitbake is the following:

#Opt	Id	Name	Type	IP	Offset	Binary
-	0x01	fsbl-boot	Binary	none	0x0	arm-trusted-firmware/tf-a-stm32mp135f-dk-usb.stm32
-	0x03	fip-boot	FIP	none	0x0	fip/fip-stm32mp135f-dk-optee.bin
P	0x04	fsbl1	Binary	mmc0	0x00004400	arm-trusted-firmware/tf-a-stm32mp135f-dk-sdcard.stm32
P	0x05	fsbl2	Binary	mmc0	0x00044400	arm-trusted-firmware/tf-a-stm32mp135f-dk-sdcard.stm32
P	0x06	metadata1	Binary	mmc0	0x00084400	arm-trusted-firmware/metadata.bin
P	0x07	metadata2	Binary	mmc0	0x000C4400	arm-trusted-firmware/metadata.bin
P	0x08	fip-a	FIP	mmc0	0x00104400	fip/fip-stm32mp135f-dk-optee.bin
PED	0x09	fip-b	FIP	mmc0	0x00504400	none
PED	0x0A	u-boot-env	Binary	mmc0	0x00904400	none
P	0x10	bootfs-a	System	mmc0	0x00984400	st-image-bootfs-openstlinux-weston-stm32mp13-disco.ext4
P	0x11	rootfs-a	FileSystem	mmc0	0x04984400	st-image-core-openstlinux-weston-stm32mp13-disco.ext4
P	0x12	userfs-a	FileSystem	mmc0	0x104984400	st-image-userfs-openstlinux-weston-stm32mp13-disco.ext4
P	0x13	bootfs-b	System	mmc0	0x114984400	st-image-bootfs-openstlinux-weston-stm32mp13-disco.ext4
P	0x14	rootfs-b	FileSystem	mmc0	0x118984400	st-image-core-openstlinux-weston-stm32mp13-disco.ext4
P	0x15	userfs-b	FileSystem	mmc0	0x146984400	st-image-userfs-openstlinux-weston-stm32mp13-disco.ext4

My machine file is currently like that :

# Enable use of extra partition(s)
ST_BOOTFS ?= "1"
ST_VENDORFS ?= "0"
ST_USERFS ?= "1"

PARTITIONS_IMAGES += "${@bb.utils.contains('ST_BOOTFS', '1', 'bootfs-a', '', d)}"
PARTITIONS_IMAGES += "${@bb.utils.contains('ST_VENDORFS', '1', 'vendorfs-a', '', d)}"
PARTITIONS_IMAGES += "rootfs-a"
PARTITIONS_IMAGES += "${@bb.utils.contains('ST_USERFS', '1', 'userfs-a', '', d)}"
PARTITIONS_IMAGES += "${@bb.utils.contains('ST_BOOTFS', '1', 'bootfs-b', '', d)}"
PARTITIONS_IMAGES += "${@bb.utils.contains('ST_VENDORFS', '1', 'vendorfs-b', '', d)}"
PARTITIONS_IMAGES += "rootfs-b"
PARTITIONS_IMAGES += "${@bb.utils.contains('ST_USERFS', '1', 'userfs-b', '', d)}"

# Define image to use for extra partitions
STM32MP_BOOTFS_IMAGE ?= "st-image-bootfs"
STM32MP_BOOTFS_LABEL ?= "bootfs-a"
STM32MP_BOOTFS_MOUNTPOINT ?= "/boot-a"
# Proposed value for bootfs is 64MB
STM32MP_BOOTFS_SIZE ?= "65536"
STM32MP_ROOTFS_IMAGE ?= "${IMAGE_BASENAME}"
STM32MP_ROOTFS_LABEL ?= "rootfs-a"
# Configure the rootfs size with IMAGE_ROOTFS_MAXSIZE variable
STM32MP_ROOTFS_SIZE ?= "${IMAGE_ROOTFS_MAXSIZE}"
STM32MP_USERFS_IMAGE ?= "st-image-userfs"
STM32MP_USERFS_LABEL ?= "userfs-a"
STM32MP_USERFS_MOUNTPOINT ?= "/usr/local-a"
# Proposed value for userfs is 128MB
STM32MP_USERFS_SIZE ?= "262144"
STM32MP_VENDORFS_IMAGE ?= "st-image-vendorfs"
STM32MP_VENDORFS_LABEL ?= "vendorfs-a"
STM32MP_VENDORFS_MOUNTPOINT ?= "/vendor-a"
# Proposed value for vendorfs is 16MB
STM32MP_VENDORFS_SIZE ?= "16384"

# <image_name>,<partition_label>,<mountpoint>,<size>,<type>
PARTITIONS_IMAGES[bootfs-a] ?= "${STM32MP_BOOTFS_IMAGE},${STM32MP_BOOTFS_LABEL},${STM32MP_BOOTFS_MOUNTPOINT},${STM32MP_BOOTFS_SIZE},System"
PARTITIONS_IMAGES[vendorfs-a] ?= "${STM32MP_VENDORFS_IMAGE},${STM32MP_VENDORFS_LABEL},${STM32MP_VENDORFS_MOUNTPOINT},${STM32MP_VENDORFS_SIZE},FileSystem"
PARTITIONS_IMAGES[rootfs-a] ?= "${STM32MP_ROOTFS_IMAGE},${STM32MP_ROOTFS_LABEL},,${STM32MP_ROOTFS_SIZE},FileSystem"
PARTITIONS_IMAGES[userfs-a] ?= "${STM32MP_USERFS_IMAGE},${STM32MP_USERFS_LABEL},${STM32MP_USERFS_MOUNTPOINT},${STM32MP_USERFS_SIZE},FileSystem"

# Define image to use for extra partitions
STM32MP_BOOTFSB_IMAGE ?= "st-image-bootfs"
STM32MP_BOOTFSB_LABEL ?= "bootfs-b"
STM32MP_BOOTFSB_MOUNTPOINT ?= "/boot-b"
# Proposed valBue for bootfs is 64MB
STM32MP_BOOTFSB_SIZE ?= "65536"
STM32MP_ROOTFSB_IMAGE ?= "${IMAGE_BASENAME}"
STM32MP_ROOTFSB_LABEL ?= "rootfs-b"
# Configure the rootfs size with IMAGE_ROOTFS_MAXSIZE variable
STM32MP_ROOTFSB_SIZE ?= "${IMAGE_ROOTFS_MAXSIZE}"
STM32MP_USERFSB_IMAGE ?= "st-image-userfs"
STM32MP_USERFSB_LABEL ?= "userfs-b"
STM32MP_USERFSB_MOUNTPOINT ?= "/usr/local-b"
# Proposed valBue for userfs is 128MB
STM32MP_USERFSB_SIZE ?= "262144"
STM32MP_VENDORFSB_IMAGE ?= "st-image-vendorfs"
STM32MP_VENDORFSB_LABEL ?= "vendorfs-b"
STM32MP_VENDORFSB_MOUNTPOINT ?= "/vendor-b"
# Proposed value for vendorfs is 16MB
STM32MP_VENDORFS_SIZE ?= "16384"

# <image_name>,<partition_label>,<mountpoint>,<size>,<type>
PARTITIONS_IMAGES[bootfs-b] ?= "${STM32MP_BOOTFSB_IMAGE},${STM32MP_BOOTFSB_LABEL},${STM32MP_BOOTFSB_MOUNTPOINT},${STM32MP_BOOTFSB_SIZE},System"
PARTITIONS_IMAGES[vendorfs-b] ?= "${STM32MP_VENDORFSB_IMAGE},${STM32MP_VENDORFSB_LABEL},${STM32MP_VENDORFSB_MOUNTPOINT},${STM32MPB_VENDORFS_SIZE},FileSystem"
PARTITIONS_IMAGES[rootfs-b] ?= "${STM32MP_ROOTFSB_IMAGE},${STM32MP_ROOTFSB_LABEL},,${STM32MP_ROOTFSB_SIZE},FileSystem"
PARTITIONS_IMAGES[userfs-b] ?= "${STM32MP_USERFSB_IMAGE},${STM32MP_USERFSB_LABEL},${STM32MP_USERFSB_MOUNTPOINT},${STM32MP_USERFSB_SIZE},FileSystem"

But when I am generating the image and then flashing it on the board, I got an unexpected error that I can't explain, happening after the kernel starts.

root '/dev/disk/by-partuuid/e91c4e10-16e6-4c0e-bd0e-77becf4a3582' doesn't exist or does not contain a /dev.

By searching through st layers, I found that sd card rootfs has its own defined uuid that is written as is in the code. I saw that fip1 and fip2 has 2 separate uuid. I wonder if I need to have 2 different uuid for my 2 rootfs. I tried to modify .wks files too, I found 2 of them, one with vendorfs and the other without.

# short-description: Create SD card image with a boot partition (1GB)
# long-description: Creates a partitioned SD card image (1GB)
#
# - -------- ------------- ------ ------ ------------ -------- --------- --------
# | | TFA(2) | Metadata(2) | FIPA | FIPB | U-BOOT ENV | bootfs | rootfs | userfs |
# - -------- ------------- ------ ------ ------------ -------- --------- --------
# ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
# | | | | | | | | | |
# 0 17kB 542kB 1.06MB 5.26MB 9.45MB 9.97MB 77.1MB 898MB 1032MB
#
# Warning: the first stage of boot (here fsbl1, fsbl2, metadata1, metadata2, fipa, fipb) MUST be on GPT partition to be detected.
#

# FSBL partitions aka TF-A BL2
part fsbl1 --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fsbl1 --sourceparams="file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware/tf-a-stm32mp135f-dk-sdcard.stm32" --ondisk mmcblk --part-type 0x8301 --fixed-size 256K --align 17
part fsbl2 --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fsbl2 --sourceparams="file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware/tf-a-stm32mp135f-dk-sdcard.stm32" --ondisk mmcblk --part-type 0x8301 --fixed-size 256K

# Metadata partitions
part metadata1 --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=metadata1 --sourceparams="file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware/metadata.bin" --ondisk mmcblk --part-type 0x8301 --fixed-size 256K
part metadata2 --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=metadata2 --sourceparams="file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware/metadata.bin" --ondisk mmcblk --part-type 0x8301 --fixed-size 256K

# Fip partitions
part fip-a --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fip-a --sourceparams="file=${DEPLOY_DIR_IMAGE}/fip/fip-stm32mp135f-dk-optee.bin" --ondisk mmcblk --part-type 19d5df83-11b0-457b-be2c-7559c13142a5 --fixed-size 4096K --uuid 4fd84c93-54ef-463f-a7ef-ae25ff887087
part fip-b --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fip-b --sourceparams="file=${DEPLOY_DIR_IMAGE}/fip/fip-stm32mp135f-dk-optee.bin" --ondisk mmcblk --part-type 19d5df83-11b0-457b-be2c-7559c13142a5 --fixed-size 4096K --uuid 09c54952-d5bf-45af-acee-335303766fb3

# U-BOOT env
part u-boot-env --source empty --part-name=uboot-env --ondisk mmcblk --part-type 0x8301 --fixed-size 512K

# Bootfs
part bootfs-a --source rawcopy --sourceparams="file=st-image-bootfs-${DISTRO}-${MACHINE}.ext4" --ondisk mmcblk --fstype=ext4 --label bootfs-a --part-name "bootfs-a" --active --fixed-size 64M
# Rootfs
part / --source rootfs-a --ondisk mmcblk --fstype=ext4 --label rootfs-a --part-name"rootfs-a" --fixed-size 783M --uuid e91c4e10-16e6-4c0e-bd0e-77becf4a3582
# Userfs
part userfs-a --source rawcopy --sourceparams="file=st-image-userfs-${DISTRO}-${MACHINE}.ext4" --ondisk mmcblk --fstype=ext4 --label userfs-a --part-name "userfs-a" --fixed-size 128M

# Bootfs
part bootfs-b --source rawcopy --sourceparams="file=st-image-bootfs-${DISTRO}-${MACHINE}.ext4" --ondisk mmcblk --fstype=ext4 --label bootfs-b --part-name "bootfs-b" --active --fixed-size 64M
# Rootfs
part / --source rootfs-b --ondisk mmcblk --fstype=ext4 --label rootfs-b --part-name "rootfs-b" --fixed-size 783M --uuid e91c4e10-16e6-4c0e-bd0e-77becf4a3583
# Userfs
part userfs-b --source rawcopy --sourceparams="file=st-image-userfs-${DISTRO}-${MACHINE}.ext4" --ondisk mmcblk --fstype=ext4 --label userfs-b --part-name "userfs-b" --fixed-size 128M

bootloader --ptable gpt

and with vendorfs

# short-description: Create SD card image with a boot partition (1GB)
# long-description: Creates a partitioned SD card image (1GB)
#
# --------------------------------------------------------------------------------------------
# | | TFA(2) | Metadata(2) | FIPA | FIPB | U-BOOT ENV | bootfs-b | vendorfs-b | rootfs-b | userfs-b |
# --------------------------------------------------------------------------------------------
# ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
# | | | | | | | | | | |
# 0 17kB 542kB 1.06MB 5.26MB 9.45MB 9.97MB 77.1MB 93.9Mb 939MB 1073MB
#
# Warning: the first stage of boot (here fsbl1, fsbl2, metadata1, metadata2, fipa, fipb) MUST be on GPT partition to be detected.
#

# FSBL partitions aka TF-A BL2
part fsbl1 --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fsbl1 --sourceparams="file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware/tf-a-stm32mp135f-dk-sdcard.stm32" --ondisk mmcblk --part-type 0x8301 --fixed-size 256K --align 17
part fsbl2 --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fsbl2 --sourceparams="file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware/tf-a-stm32mp135f-dk-sdcard.stm32" --ondisk mmcblk --part-type 0x8301 --fixed-size 256K

# Metadata partitions
part metadata1 --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=metadata1 --sourceparams="file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware/metadata.bin" --ondisk mmcblk --part-type 0x8301 --fixed-size 256K
part metadata2 --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=metadata2 --sourceparams="file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware/metadata.bin" --ondisk mmcblk --part-type 0x8301 --fixed-size 256K

# Fip partitions
part fip-a --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fip-a --sourceparams="file=${DEPLOY_DIR_IMAGE}/fip/fip-stm32mp135f-dk-optee.bin" --ondisk mmcblk --part-type 19d5df83-11b0-457b-be2c-7559c13142a5 --fixed-size 4096K --uuid 4fd84c93-54ef-463f-a7ef-ae25ff887087
part fip-b --source rawcopy --fstype=ext4 --fsoptions "noauto" --part-name=fip-b --sourceparams="file=${DEPLOY_DIR_IMAGE}/fip/fip-stm32mp135f-dk-optee.bin" --ondisk mmcblk --part-type 19d5df83-11b0-457b-be2c-7559c13142a5 --fixed-size 4096K --uuid 09c54952-d5bf-45af-acee-335303766fb3

# U-BOOT env
part u-boot-env --source empty --part-name=uboot-env --ondisk mmcblk --part-type 0x8301 --fixed-size 512K

# Bootfs
part bootfs-a --source rawcopy --sourceparams="file=st-image-bootfs-${DISTRO}-${MACHINE}.ext4" --ondisk mmcblk --fstype=ext4 --label bootfs-a --part-name "bootfs-a" --active --fixed-size 64M
# Vendorfs
part vendorfs-a --source rawcopy --sourceparams="file=st-image-vendorfs-${DISTRO}-${MACHINE}.ext4" --ondisk mmcblk --fstype=ext4 --label vendorfs-a --part-name "vendorfs-a" --fixed-size 16M
# Rootfs
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label rootfs-a --part-name "rootfs-a" --fixed-size 772M --uuid e91c4e10-16e6-4c0e-bd0e-77becf4a3582
# Userfs
part userfs-a --source rawcopy --sourceparams="file=st-image-userfs-${DISTRO}-${MACHINE}.ext4" --ondisk mmcblk --fstype=ext4 --label userfs-a --part-name "userfs-a" --fixed-size 128M

# Bootfs
part bootfs-b --source rawcopy --sourceparams="file=st-image-bootfs-${DISTRO}-${MACHINE}.ext4" --ondisk mmcblk --fstype=ext4 --label bootfs-b --part-name "bootfs-b" --fixed-size 64M
# Vendorfs
part vendorfs-b --source rawcopy --sourceparams="file=st-image-vendorfs-${DISTRO}-${MACHINE}.ext4" --ondisk mmcblk --fstype=ext4 --label vendorfs-b --part-name "vendorfs-b" --fixed-size 16M
# Rootfs
part /rootfs-b --source rootfs --ondisk mmcblk --fstype=ext4 --label rootfs-b --part-name "rootfs-b" --fixed-size 772M --uuid e91c4e10-16e6-4c0e-bd0e-77becf4a3583
# Userfs
part userfs-b --source rawcopy --sourceparams="file=st-image-userfs-${DISTRO}-${MACHINE}.ext4" --ondisk mmcblk --fstype=ext4 --label userfs-b --part-name "userfs-b" --fixed-size 128M

bootloader --ptable gpt

I also saw another post on this forum (https://community.st.com/t5/stm32-mpus-embedded-software/change-u-boot-variables-for-different-rootfs-bootfs-partitions/m-p/206170) where 3 boot partition were needed. One for a script and the 2 others containing kernel, etc... I'm just a beginner, sorry if I forgot something very important in my process. Thank you for your time.

    This topic has been closed for replies.
    Best answer by Christophe Guibout

    Hello @retroll,

    From my point of view, I would suggest to manage A/B mechanism outside Yocto build, because an update image can go to A or B without any knowledge.

    So I would suggest to build an image with Yocto like a normal one, where A is the default boot.
    Your memory mapping looks good.

    Regarding your boot issue, you can fix it by updating your machine in conf/machine/include/st-machine-extlinux-config-stm32mp.inc:

    -UBOOT_EXTLINUX_ROOT:target-sdcard = "root=PARTUUID=${DEVICE_PARTUUID_ROOTFS:SDCARD}"

    +UBOOT_EXTLINUX_ROOT:target-sdcard = "root=PARTLABEL=rootfs-a"

    When you will update your system, you will switch from A to B, so after having flashed B partitions with nex image, you will have to update mount points so that new image will boot on B (ex: kernel cmdline to be updated to boot on bootfs-b instead of bootfs-a).

    Hope I'am clear enough.

    BR,

    Christophe

    2 replies

    C
    Christophe GuiboutAnswer
    ST Employee
    November 6, 2023

    Hello @retroll,

    From my point of view, I would suggest to manage A/B mechanism outside Yocto build, because an update image can go to A or B without any knowledge.

    So I would suggest to build an image with Yocto like a normal one, where A is the default boot.
    Your memory mapping looks good.

    Regarding your boot issue, you can fix it by updating your machine in conf/machine/include/st-machine-extlinux-config-stm32mp.inc:

    -UBOOT_EXTLINUX_ROOT:target-sdcard = "root=PARTUUID=${DEVICE_PARTUUID_ROOTFS:SDCARD}"

    +UBOOT_EXTLINUX_ROOT:target-sdcard = "root=PARTLABEL=rootfs-a"

    When you will update your system, you will switch from A to B, so after having flashed B partitions with nex image, you will have to update mount points so that new image will boot on B (ex: kernel cmdline to be updated to boot on bootfs-b instead of bootfs-a).

    Hope I'am clear enough.

    BR,

    Christophe

      R
      retrollAuthor
      Graduate
      November 7, 2023

      Thank you for your explanation. But I have been provided a solution via the meta-st-ota layer, that implement both the partionning and update system with rauc that will help me a lot. I still tried to implement the solution you gave me, but it appears that I broke something else before and now, the bootloader is unable to find the bmp image. Now instead of having the choice between OpenStLinux and stm32mp13dk at boot, the OpenStLinux has been replaced by rootfs-a. I have to find out why. I'll come back here if I achieve to fix it and implement your solution.

      C
      Christophe Guibout
      ST Employee
      November 15, 2023

      Hello @retroll,

      I would recommand to cross-check that the correction I proposed in st-machine-extlinux-config-stm32mp.inc is well taken into account in your compilation : it updates the kernel cmdline by replacing the root mount point path from "by-partuuid" to "by-partlabel".

      BR,

      Christophe

      BR,

      Christophe

        R
        retrollAuthor
        Graduate
        November 15, 2023

        Hello,

        I first compared the 2 u-boot environment, the demo one (which is working) and mine, which is not. In the first one. In the first one, I saw a line about extlinux: boot_syslinux_conf=extlinux/extlinux.conf

        In the second one, this line was replaced by boot_syslinux_conf=extlinux/stm32mp135f-dk_extlinux.conf

        Which means that for whatever reason, the extlinux used was not the same. There was several other differences, but it doesn't seem to be that meaningful. Here is a diff of my 2 u-boot envs if it helps (incoming changes are mine):

        1d0
< altboot=0
14c13
< boot_extlinux=run scan_m4fw;run scan_overlays; sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${pre}
---
> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
16d14
< boot_m4fw=rproc init; rproc load 0 ${m4fw_addr} ${filesize}; rproc start 0
18c16
< boot_prefixes=/mmc0_
---
> boot_prefixes=/ /boot/
21,22c19,20
< boot_syslinux_conf=extlinux/stm32mp135f-dk_extlinux.conf
< boot_targets=mmc0
---
> boot_syslinux_conf=extlinux/extlinux.conf
> boot_targets=mmc1 ubifs0 mmc0 usb0 pxe 
31d28
< bootfstype=ext4
34d30
< devplist=8 9
44,45d39
< fileaddr=c4100000
< filesize=efd
49,50d42
< m4fw_addr=0xc2000000
< m4fw_name=rproc-m4-fw.elf
52,53d43
< ov_apply=test -n ${fdtovaddr} && test -n ${overlay} && for ov in ${overlay}; do echo overlaying ${ov}...; load ${devtye
< ov_init=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${fdtfile} && env set fdt_addr ${fdt_addr_r} && fdt0
61,62d50
< scan_m4fw=if test -e ${devtype} ${devnum}:${distro_bootpart} ${m4fw_name};then echo Found M4 FW $m4fw_name; if load ${;
< scan_overlays=if test -e ${devtype} ${devnum}:${distro_bootpart} /overlays/overlays.txt && load ${devtype} ${devnum}:$i
72c60
< Environment size: 5416/8187 bytes
---
> Environment size: 4284/8187 bytes

        I then research for stm32mp135f-dk_extlinux.conf in the build dir (build/tmp-glibc/work/stm32mp1_ota-ostl-linux-gnueabi/stm32mp-extlinux/3.1.1-r0/build/mmc0_extlinux/stm32mp135f-dk_extlinux.conf) as it contain the cmdline. And it appears the indeed, in my build, it is still by-partuuid:

         

        # Generic Distro Configuration file generated by OpenEmbedded
menu title Select the boot mode
MENU BACKGROUND /splash_landscape.bmp
TIMEOUT 20
DEFAULT OpenSTLinux
LABEL OpenSTLinux
	KERNEL /uImage
	FDTDIR /
	INITRD /st-image-resize-initrd
	APPEND root=PARTUUID=e91c4e10-16e6-4c0e-bd0e-77becf4a3582 rootwait rw rauc.slot=A console=${console},${baudrate}
LABEL stm32mp135f-dk-a7-examples
	KERNEL /uImage
	FDT /stm32mp135f-dk-a7-examples.dtb
	INITRD /st-image-resize-initrd
	APPEND root=PARTUUID=e91c4e10-16e6-4c0e-bd0e-77becf4a3582 rootwait rw rauc.slot=A console=${console},${baudrate}

         

         The same file on the demo contain the right label and not the uuid. I can't find why the u-boot env is different and why these extlinux files are not what they are supposed to be. I obviously tried several time to rebuild from scratch. I also noticed that the meta-st-ota is anyway using its own copy of st-machine-extlinux-config-stm32mp.inc, where either for sdcard and for emmc, uuid is replaced by rootfs-a.

         

        Many thanks for your help on my case, you are very helpful.

        R
        retrollAuthor
        Graduate
        November 15, 2023

        Ok I found the final answer for my meta-st-ota to work in my configuration. All is dictated by the layer order in the bblayers.conf. I needed to put meta-rauc and meta-st-ota just before meta-stm32mp layer. My bblayers.conf was inspired by the one generated in the demo project but simplified. I haven't noticed that rauc and ota layers were prepend instead of append (BBLAYERS =+ and not +=). And for the manual implementation of all of it, without the ota layers, it seems that the solution given in the first place was the good answer.

        Terms & ConditionsAccessibility statement