A/B partitions using scarthgap on stm32mp25

[BGurnett]

We have a custom stm32mp25 board. On Mickledore we were able to create a/b partitions in our machine conf doing the following:

 

 

 

PARTITIONS_IMAGES += "tc-appfs-a tc-appfs-b"

STM32MP_TCFS_IMAGE ?= "ti-tc-appfs"
STM32MP_TCFS_LABEL_A ?= "tc-appfs-a"
STM32MP_TCFS_LABEL_B ?= "tc-appfs-b"
STM32MP_TCFS_MOUNTPOINT ?= "/tc-apps"
# Proposed value for tc-appfs is 150MB
STM32MP_TCFS_SIZE ?= "153600"



PARTITIONS_IMAGES[tc-appfs-a] ?= "${STM32MP_TCFS_IMAGE},${STM32MP_TCFS_LABEL_A},${STM32MP_TCFS_MOUNTPOINT},${STM32MP_TCFS_SIZE},FileSystem"

PARTITIONS_IMAGES[tc-appfs-b] ?= "${STM32MP_TCFS_IMAGE},${STM32MP_TCFS_LABEL_B},${STM32MP_TCFS_MOUNTPOINT},${STM32MP_TCFS_SIZE},FileSystem"



PARTITIONS_LIST += "tc-appfs-a tc-appfs-b"

 

 

However, in scarthgap this no longer works. We are getting the following error:

Cannot generate FlashLayout_emmc_stm32mp257f-m670-optee.tsv file: the ti-tc-appfs-ti-linux-stm32mp25-m670.tc-appfs-a.ext4 binary for tc-appfs-a partition is missing in deploy folder.

What we observe is that the relevant file is being renamed as

ti-tc-appfs-ti-linux-stm32mp25-m670.tc-appfs-bfs.ext4

Is this a bug, or do we need to proceed in a different way when using scarthgap.

 

Thanks

 

P.S I have seen mentioned an meta-st-ota layer on the board. I have, however, been unable to find it. So if someone could point out it's location I would be grateful.

[Christophe Guibout]

Hello @BGurnett,

 

So, according to your logs, it seems a "fs" suffix is appent to the filename.

 

In st-machine-image-partition-stm32mp.inc, It seems the generated filename doesn't contain the "fs" suffix:

bin_name = items[0] + bin_suffix + '.' + items[1] + '.' + fstype

Where bin_suffix = '-${DISTRO}-${MACHINE}'

 

Nevertheless, the image filename has change between Mickledore and Scrathgap, here is an example for bootfs partition:

Mickledore: st-image-bootfs-openstlinux-weston-stm32mp2.ext4

Scrathgap: st-image-bootfs-openstlinux-weston-stm32mp2.bootfs.ext4

  

Is "fs" suffix added on all your partitions ? Or only ext4 ones ?

BR,

Christophe

 

PS: I asked to give you the permission to access to meta-st-ota.

 

[pp2]

Hi, may I also get an access to meta-st-ota? I've been evaluation mp2 for our next platform and robust fwupdate is a crucial feature that I need to confirm is working as we would expect. 

[BGurnett]

Hi

The addition of fs, and the change of the image name seems to occur on all partitions and all files (manifest, spdx etc), with the exception of tar.xz which keeps the original name, but no link is generated for it when trying to make A/B partitions.

 

 

[BGurnett]

Hello

Is there any more info or tests I can perform in order to get things moving along. Also I have managed to get rauc to update partitions. However, for some reason, on reboot the partitions are not switching. After the update, and before reboot, i run rauc status and both A and B partitions are good, so everything looks ok, with the exception that no switching occurs.

 

kind regards

[Christophe Guibout]

Hi @BGurnett,

 

I wrote a wiki page on that topic, but it is not yet published because still under review.

First of all, I would recommand to read the Secure Firmware Update wiki page.

Then, the best way to update metadata partition is to use mkfwumdata tool, with an extra patch which will be integrated by default in the next v6.1.0 Ecosystem Release : link.

 

So here are steps:

• Prerequisite: system is running on bank A (fip-a, bootfs-a, rootfs-a...)
• The update manager which is in touch with the software provisioning server is notified about a new update that will be written into bank B (fip-b, bootfs-b, rootfs-b...)
• When the new image is downloaded into the bank B, the update manager:
  • can execute some scripts to adapt the new flashed image to bank B (ex: partition mount points)
  • update the metadata partition to request TF-A to try to boot on the new bank B: so the update manager will change the metadata partition by:
    • updating active_index to bank B (see -a option), so bank A becomes previous_active_index (see -p option)
    • switching bank B as Valid (see -s option). Bank A will be kept as Accepted, in case of failure of bank B.

UUID_LIST="8a7a84a0-8387-40f6-ab41-a8b9a5a60d23,19d5df83-11b0-457b-be2c-7559c13142a5,4fd84c93-54ef-463f-a7ef-ae25ff887087,09c54952-d5bf-45af-acee-335303766fb3"

OPTIONS="-g -i 1 -b 2 -v 2" bank_state="A,V"

mkfwumdata ${OPTIONS} -s ${bank_state} -a 1 -p 0 ${UUID_LIST} /dev/disk/by-partlabel/metadata1

mkfwumdata ${OPTIONS} -s ${bank_state} -a 1 -p 0 ${UUID_LIST} /dev/disk/by-partlabel/metadata2

Don't forget to update /dev/disk/by-partlabel/metadata2 which is the backup of metadata1, and will be used by TF-A in case of CRC error of metadata1 partition.

 

• On reboot, TF-A will boot bank B, and we have now two possibilities:
  • bank B crashs: as the watchdog is enabled, the platform will reboot on crash. As bank B is in trial mode, the bootcount is decremented on each reboot. After 3 attempts (default value), TF-A will consider the bank B is not able to boot, so it will switch back to bank A. As active_index is bank B, but bank A is active, the update manager can consider bank B as Invalid, and notify the software provisioning server if needed.
  • bank B successfully boots: the update manager from bank B can update the metadata partition to switch the bank B state to Accepted: on the next reboot, TF-A will consider this bank Accepted, and will disable the bootcount:

UUID_LIST="8a7a84a0-8387-40f6-ab41-a8b9a5a60d23,19d5df83-11b0-457b-be2c-7559c13142a5,4fd84c93-54ef-463f-a7ef-ae25ff887087,09c54952-d5bf-45af-acee-335303766fb3"

OPTIONS="-g -i 1 -b 2 -v 2" bank_state="A,A"

mkfwumdata ${OPTIONS} -s ${bank_state} -a 1 -p 0 ${UUID_LIST} /dev/disk/by-partlabel/metadata1

mkfwumdata ${OPTIONS} -s ${bank_state} -a 1 -p 0 ${UUID_LIST} /dev/disk/by-partlabel/metadata2

BR,

Christophe Guibout

 

[BGurnett]

Aren't these steps mentioned above already being performed by the post-install.sh st-boot-script.sh st-status-mark-good.sh in conjunction with update_metadata.sh. These are all being run, but do not seem to affect the switching.

 

current_boot_slot=A
rootfs-b PARTUUID updated: 83e1fd5c-45cd-43f9-a888-be9bd503ce1d
[ 1327.086624] EXT4-fs (mmcblk0p7): mounted filesystem 6a717db6-1964-4756-bef1-1a7435c4f5ad r/w with ordered data mode. Quota mode: none.
Updating: /tmp/boot_B/mmc0_extlinux/extlinux.conf
Updating: /tmp/boot_B/mmc1_extlinux/extlinux.conf
umount to /tmp/boot_B
[ 1327.142304] EXT4-fs (mmcblk0p7): unmounting filesystem 6a717db6-1964-4756-bef1-1a7435c4f5ad.
[ 1327.176997] EXT4-fs (mmcblk0p11): mounted filesystem 2b2bc479-748a-42e0-baff-7e4fe7727532 r/w with ordered data mode. Quota mode: none.
umount to /tmp/rootfs_B
[ 1327.227210] EXT4-fs (mmcblk0p11): unmounting filesystem 2b2bc479-748a-42e0-baff-7e4fe7727532.
writing metadata partitions....
mkfwumdata -g -i 1 -b 2 -v 2 -s A,V -a 1 -p 0 8a7a84a0-8387-40f6-ab41-a8b9a5a60d23,19d5df83-11b0-457b-be2c-7559c13142a5,4fd84c93-54ef-463f-a7ef-ae25ff887087,09c54952-d5bf-45af-acee-335303766fb3
active boot is B
boot count is enabled

 

so atleast according from above, we should be booting into B, or am I missing something fundamental?