How to explicitly set partitions UUIDs for rootfs-a and rootfs-b during flashing?

[mmichala]

Hello,

for flashing my STM32MP135F-DK board I am using STM_Programmer_CLI with my .tsv file. Example command and my tsv file:

sudo ./STM32_Programmer_CLI -c port=usb1 -w path/to/my.tsv

Is there a way to explicitly set partitions UUID for rootfs-a and rootfs-b during flashing?

I've noticed that when I name a partition with rootfs then it gets UUID of e91c4e10-16e6-4c0e-bd0e-77becf4a3582, as described in the wiki . But when having rootfs-a and rootfs-b, then those partitions get some other UUID, and the boot stops because rootfs UUID is not e91c4e10-16e6-4c0e-bd0e-77becf4a3582.

I need the rootfs-a and rootfs-b UUIDs to be constant, to manage FW upgrades.

[Christophe Guibout]

Hello @mmichala,

I guess you use meta-st-ota layer : to avoid that problem, I would recommand to flash the image into the sdcard with create_sdcard_from_flashlayout.sh script available in the layer, where bootfs-b UUID is managed.

Neverthless, I take the point to bring rootfs-b support in CubeProgrammer (and also rootfs-a/b, vendorfs-a/b...).

BR,

Christophe

[mmichala]

@Christophe Guibout 

When using STM32MP135F-DK I have a possibility to take SD card out and plug it into host PC to use create_sdcard_from_flashlayout.sh script and 'dd' to populate it.

But STM32MP135F-DK is only my test/development board, and for production I will be using another hardware with eMMC. That's why I've already used STM_Programmer_CLI method even for STM32MP135F-DK.

Now there is a problem for me, because the development time is ticking and I can't get OTA working. Previously I was using Yocto kirkstone, and meta-st-ota for kirkstone was using partition labels, which was working fine when migrated to my project.

But I had to upgrade Yocto from Kirkstone to Scarthgap, and that's why I also updated meta-st-ota.

May I ask you @Christophe Guibout , when approximately will this support in CubeProgrammer be ready?

Best Regards
Mateusz

[Christophe Guibout]

Hello @mmichala,

Instead of configuring an hardcoded PARTUUID for rootfs-b, I think it's better to read it at runtime (with blkid) in order to update the kernel command line accordingly.

I updated the meta-st-ota layer with this correction.

BR,

Christophe

[mmichala]

Hello @Christophe Guibout 

thank you for your answer and commiting to the repo.

I tested it and have two concerns:

1. To get the default partUUID (e91c4e10-16e6-4c0e-bd0e-77becf4a3582) for rootfs slot A, I have to name it 'rootfs' not 'rootfs-a' in my .tsv, otherwise the partUUID given by STM_Programmer is random, and system doesn't boot from slot A. But this is not a big problem though.
2. As far as I understand, 'blkid' used in post-install.sh to discover rootfs-b partUUID, prints filesystem UUID, not partition UUID. What is more, both A and B rootfs partitions have filesystems named 'rootfs' so the Python code failes to find 'rootfs-b'.

[Christophe Guibout]

Hello @mmichala,

I fixed partUUID issue seen with CubeProgrammer:

- I've created a tsv file for eMMC on top of stm32mp257f-ev1 board (with bootfs-a and bootfs-b)

- The default partUUID (e91c4e10-16e6-4c0e-bd0e-77becf4a3582) was set for the partition named "rootfs" only : with the patch available in u-boot, this partUUID is also applied for rootfs-a partition.

Please fetch the meta-st-ota layer to get the corrections.

BR,

Christophe

[mmichala]

Hello @Christophe Guibout 

Great, now the UUID of e91c4e10-16e6-4c0e-bd0e-77becf4a3582 is being successfully assigned to partition
'rootfs-b'. Thanks

Still, the second problem I have described was still occuring. I mean the 'blkid' returning filesystem UUID, not GPT partition UUID. They were not equal in my case.
What is more, 'blkid' output was always 'rootfs' (I guess the FS name) not 'rootfs-a' and 'rootfs-b' (partnames) defined in .tsv file.

To deal with that, I have changed the recently added get_rootfsb_uuid function in post_install.sh

This version works for me, it uses /dev/disk/by-partuuid:

# Discover rootfs-b UUID
def get_rootfsb_uuid():
     # Step 1: Discover which partition corresponds to the label 'rootfs-b'
    partlabel_path = "/dev/disk/by-partlabel"
    # Iterate through the symlinks in the by-partlabel directory
    for entry in os.listdir(partlabel_path):
        if entry == "rootfs-b":
            target = os.readlink(os.path.join(partlabel_path, entry))  # Read the symlink target
            partition = os.path.basename(target)  # Extract device name (e.g., mmc0p11)
            print(f"Partition for label 'rootfs-b' is: /dev/{partition}")
            break
    else:
        print("Error! Partition with partname 'rootfs-b' not found.")
        return 1
    # Step 2: Find the UUID of the partition using /dev/disk/by-partuuid
    partuuid_path = "/dev/disk/by-partuuid"
    # Iterate through the symlinks in the by-partuuid directory
    for entry in os.listdir(partuuid_path):
        target = os.readlink(os.path.join(partuuid_path, entry))  # Read the symlink target
        if partition in target:
            uuid = entry  # The symlink name is the UUID
            print(f"UUID for partition '{partition}' is: {uuid}")
            # Update UUIDs dictionary
            uuid_dico["rootfs"]["B"]=uuid
            return 0
    else:
       print(f"Error! {partition} UUID not found.") 
       return 1

[Christophe Guibout]

Hi @mmichala,

Thanks for your feedback,

On my side, it seems PARTUUID returned by blkid is similar with guid returned in u-boot (mmc dev 0 ; mmc part), but /dev/disk/by-partuuid is different.

I will dig into this later, as you're not blocked anymore.

BR,

Christophe