2023-10-16 04:37 AM
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.
Solved! Go to Solution.
2023-11-06 01:03 AM
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
2023-11-06 01:03 AM
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
2023-11-07 04:14 AM
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.
2023-11-14 03:11 AM
Hello again, after sevral days testing thigns with the meta-st-ota and meta-rauc layers, I'm stuck at the same point with the same problem. If I build the demo given here https://wiki.st.com/stm32mpu/wiki/STM32MP1_Distribution_Package and following the exact steps given in the readme of meta-st-ota, it works correctly, but when I try to integrate it to my architecture, same error:
root '/dev/disk/by-partuuid/e91c4e10-16e6-4c0e-bd0e-77becf4a3582' doesn't exist or does not contain a /dev.
I tried to copy paste meta-st folder to get the same revision of st layers but nothing do it, and the fix you gave me is actually not working for this error. I'm lost.
2023-11-15 12:16 AM
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
2023-11-15 12:27 AM - edited 2023-11-15 12:31 AM
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.
2023-11-15 06:31 AM
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.