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'.