STM32MP15 ECO 5.0.0 metadata.bin

[debugging]

The TF-A Makefile.sdk creates a small metadata.bin file for each type of boot (USB, SD-cARD, EMMC)

1/ How to generates this outside of Makefile.sdk  ? I use this, but is only generates one file and there seems no parameter for the type of the boot device;

TF_A_METADATA_JSON=plat/st/stm32mp1/default_metadata.json
tools/fwu_gen_metadata/fwumd_tool.py jsonparse $TF_A_METADATA_JSON -b build/stm32mp1/metadata.bin

2/ Is the file the same for each device different or can it be used for SD, EMMC, USB  etc.. ?

3/ is there a specification for the format of this file ?

4/ is there a tool to enumerate the entries and their values in of this file ?

[michiel.tjampens]

Did some searching in the yocto setup, it's pretty much the same as what you found. But I didn't find any indication that the file depends on the media.

Source: layers/meta-st/meta-st-stm32mp/recipes-bsp/trusted-firmware-a/tf-a-stm32mp.inc

# Set metadata generation
TF_A_ENABLE_METADATA ??= "${@bb.utils.contains('MACHINE_FEATURES', 'fw-update', '1', '0', d)}"
TF_A_METADATA_NAME ?= "metadata"
TF_A_METADATA_SUFFIX ?= "bin"
TF_A_METADATA_BINARY ??= "${TF_A_METADATA_NAME}.${TF_A_METADATA_SUFFIX}"

TF_A_METADATA_TOOL ?= "tools/fwu_gen_metadata/fwumd_tool.py"
TF_A_METADATA_JSON ?= "plat/st/stm32mp1/default_metadata.json"

// Further down in the file
if [ "${TF_A_ENABLE_METADATA}" = "1" ]; then
        ${S}/${TF_A_METADATA_TOOL} jsonparse "${S}/${TF_A_METADATA_JSON}" -b "${B}/${TF_A_METADATA_NAME}.${TF_A_METADATA_SUFFIX}"
    fi

Seems like building it or not depends only depends on 'fw-update' being a requested feature or not?

[michiel.tjampens]

Something I've noticed. So this is the default_metadata.json.

{
    "copyright": "Copyright (c) 2022, STMicroelectronics - All Rights Reserved",
    "license": "SPDX-License-Identifier: BSD-3-Clause",

    "metadata": {
        "version": 0,
        "active_index": 0,
        "previous_active_index": 1,
        "img_entry": {
            "img_0": {
                "location": "device0",
                "img_bank_info": {
                    "img_0_bank_0": {
                        "accepted": true
                    },
                    "img_0_bank_1": {
                        "accepted": false
                    }
                }
            }
        }
    },
    "uuids": {
        "locations": {
            "device0": "00000000-0000-0000-0000-000000000000"
        },
        "entries": {
            "img_0_bank_0": "4fd84c93-54ef-463f-a7ef-ae25ff887087",
            "img_0_bank_1": "09c54952-d5bf-45af-acee-335303766fb3",
            "img_0":        "19d5df83-11b0-457b-be2c-7559c13142a5"
        }
    },
    "configs": {
        "nb_fw_img": 1,
        "nb_fw_banks": 2
    }
}

 I thought that those numbers looked a lot like guid of partitions.... So part of the mmc part info for an emmc containing the bitbake st build.

3	0x00000c00	0x00002bff	"fip-a"
	attrs:	0x0000000000000000
	type:	19d5df83-11b0-457b-be2c-7559c13142a5
		(19d5df83-11b0-457b-be2c-7559c13142a5)
	guid:	4fd84c93-54ef-463f-a7ef-ae25ff887087
4	0x00002c00	0x00004bff	"fip-b"
	attrs:	0x0000000000000000
	type:	19d5df83-11b0-457b-be2c-7559c13142a5
		(19d5df83-11b0-457b-be2c-7559c13142a5)
	guid:	09c54952-d5bf-45af-acee-335303766fb3

Based on those two things outputs

• img_0_bank_0 = guid of the partition containing fip-a
• img_0_bank_1 = guid of the partition containing fip-b
• img_0 = type of those partitions
• configs->nb_fw_img = 1 , because there's one fip.bin
• configs->nb_fw_banks = 2 , because it's kept in two partitions

Which would mean that the file isn't relevant for USB and probably the same for emmc,sd etc.

[michiel.tjampens]

One thing I still didn't understand was how the partitions got their respective guid.

According to this section, Cubeprogrammer sets the guid to match that of the default_metadata file (if you use .tsv). Given that there's no mention of storage/boot medium, this probably doesn't matter. Also doubt it's platform dependend, seems more like a standard that should be honored to allow fw update.

[Notitowa]

@stevensleisa  are you a real person using ChatGPT or an ST bot ?

[debugging · Accepted solution]

 When you following that link. you will find https://wiki.st.com/stm32mpu/wiki/Secure_Firmware_Update#Metadata  and from there https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.8-stm32mp/include/drivers/fwu/fwu_metadata.h  and thus the metadata structure. That WIKI is related to firmware update.

Note that Metadata are only read by the TF-A, F-A will load, verify, then boot software of the FIP found at the active_index

So, metadata defines which FIP to load. so in theory you could have multiple FIPs in the EMMC and SD and the modify metadata.bin to load another FIP (u-boot/Op-tee) on the media but the actual use case seem that  TF-A uses this for updates. Perhaps this changing of metadata can also be done by a running OS  and that would means it ot be insecure. I have not tried it. (still stuck at AXI 480) :weary_face:

Bottom line, the metadata contents seems not related to the type of media to boot from.

The metadata describes the status of a firmware update process. It define wheres to find all FIP, and stores the status of an update process:

• regular: points to a FIP which is known working. The BL2 will load and run this FIP.
• trial: a new fip has been downloaded, but is not yet accepted. The metatadata also stores the last known working fip. The BL2 will load and run the new FIP, but if the BL2 (thanks to FWU_INFO TAMP backup register) detects the boot already fails 3 times, it will load and run the last accepted FIP.

[Lina DABASINSKAITE]

Hello @Notitowa , 

The previous answer has been removed because it is as inaccurate ChatGPT response by community member. There is no ST Bot in this forum so if you feel the content is suspicious, report the message by clicking "Mark Inappropriate Content" and moderators will take further action. Here you can find how to do so: Flagging posts for moderation - STMicroelectronics Community

Regards,
Lina

[debugging]

Note: I found the command for metadata bin above -b option seems not working when using environment variables for the output path AND when there is no existing metdataa.bin file in that location. Change the command as follows, then copy the metadata.bin file to somewhere else if needed.

TF_A_METADATA_JSON=plat/st/stm32mp1/default_metadata.json

tools/fwu_gen_metadata/fwumd_tool.py jsonparse $TF_A_METADATA_JSON -b metadata.bin