How to modify metadata.bin file?

[longfeili_00001]

Hello

I am working on the multi-system in STM32MP257-EV board, I had modified the tsv file to prepare a double system A and B. If using the default metadata.bin file, the A system will be run always. Now I want the B system to be run, I need to modify the metadata.bin file, for example change the "accepted" of B bank to false:

If the status of img_0_bank_1 is trial, the B bank system will be run when ev board power up, isn't it?

how to modify the metadata.bin?

If the status of img_0_bank_1 has been modified to trial, and the B bank system run up normally, is the status of img_0_bank_1 modified automatically by linux? how does the linux system modify the metadata.bin file?

[Christophe Guibout · Accepted solution]

Hi @longfeili_00001,

I written a wiki page which answers to your question, but it's not yet published.

I copy paste the content of the article:

How to update the metadata content?

The mkfwumdata tool (from U-Boot) is used to generate the metadata partition.

Metadata generation is described in the following wiki article: Metadata generation tool, nevertheless, this version of mkfwumdata doesn't support valid bank state (only accepted and invalid are supported).

So, please apply the following patch in U-Boot to bring the feature (this patch will be integrated in v6.1.0 Ecosystem Release): autoboot-propagate-boot-index.patch .

FWU states vs Firmware Update states

FWU metadata considers three states where two of them can correspond to Firmware update state machine:

• the FWU state Valid is the Firmware update state machine regular state
• the FWU state Invalid has no corresponding Firmware update state machine state.
• the FWU state Accepted is the Firmware update state machine trial state
• The Firmware update state machine staging state has no corresponding FWU state.

Steps to run a FOTA update

• 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

This can be done in a systemd service:

$ cat status-mark-good.service [Unit] Description=Good-marking Service [Service] ExecStart=/bin/bash /usr/bin/st-status-mark-good.sh [Install] WantedBy=multi-user.target

where st-status-mark-good.sh script asks the update manager to update the metadata partition to switch the bank B state to Accepted.

BR,

Christophe

[longfeili_00001]

Hello Christophe

Thanks for your reply!

I had add the patch into my uboot code and rebuilt the uboot, but no new mkfwumdata tool generated. The following is the command used to build the uboot:

make -f $PWD/../Makefile.sdk DEPLOYDIR=$FIP_DEPLOYDIR_ROOT/u-boot UBOOT_CONFIG="default programmer" UBOOT_DEFCONFIG=stm32mp25_defconfig UBOOT_BINARY=u-boot.dtb DEVICE_TREE=stm32mp257f-ev1 FIP_CONFIG="optee-sdcard optee-programmer-usb" all

can this command build out the new mkfwumdata tool? 

how does the mkfwumdata tool generated?

[Christophe Guibout]

In configs/stm32mp25/defconfig:

CONFIG_TOOLS_MKFWUMDATA=y

Then,

make stm32mp25_defconfig

make DEVICE_TREE=stm32mp257f-ev1 all -j12

BR,

Christophe

[longfeili_00001]

hello Christophe

the new mkfwumdata tool has been generated:

./mkfwumdata --help
Usage: mkfwumdata [options] <UUIDs list> <output file>
Options:
-i, --images <num> Number of images (mandatory)
-b, --banks <num> Number of banks (mandatory)
-v, --version Metadata version (mandatory)
-s, --bank-state <val> list of bank states (default=A (accepted), V(valid) or I(invalid)
-a, --active-bank <num> Active bank (default=0)
-p, --previous-bank <num> Previous active bank (default=active_bank - 1)
-g, --guid Use GUID instead of UUID
-V, --vendor-file Vendor data file to append to the metadata
-h, --help print a help message

And regenerate the metadata.bin file use the following command:

./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 ~/metadata_tool/metadat
a.bin

Then, I use the fwumd_tool.py tool in tf-a transfer bin file to json file:

./fwumd_tool.py binparse ~/metadata_tool/metadata.bin -j ~/metadata_tool/metadata.json

Then, cat it to check if the status of bank changed or not, and it looks like the new tool not work:

cat ~/metadata_tool/metadata.json
{
"metadata": {
"crc_32": 3929930603,
"version": 2,
"active_index": 1,
"previous_active_index": 0,
"img_entry": {
"img_0": {
"location": "loc_00010002_0050_0018_83df_d519b0117b45",
"img_bank_info": {
"img_0_bank_0": {
"accepted": true,
"reserved": 588097189
},
"img_0_bank_1": {
"accepted": true,
"reserved": 0
}
}
}
}
},

[Christophe Guibout]

@longfeili_00001,

The tool named fwumd_tool.py is only compatible with metadata v1.

The tool named mkfwumdata is only compatible with metadata v2.

Here, you used fwumd_tool.py with metadata v2.

To check if the metadata is well built with mkfwumdata, write the generated file into metadata partitions, are reboot the platform to check the impact in TF-A.

BR,

Christophe

[longfeili_00001]

Hello

Thanks very much, it looks work well.