Recommend usage of partition type GUIDs to find firmware

[xypron]

If the firmware is loaded from a GPT partitioned medium, it should use the partition type GUID (and not sector number or partition number) to identify the relevant partition. This GUID should be unique for each board type.

[samueldr]

What's the definition of board type here?

AFAICT board type isn't used in the currently rendered version (2.1.0). Is there a glossary of terms I missed?

[xypron]

Am 5. Mai 2023 19:31:14 MESZ schrieb Samuel Dionne-Riel ***@***.***>:

What's the definition of *board type* here? AFAICT *board type* isn't used in the [currently rendered version (2.1.0)](https://arm-software.github.io/ebbr/). Is there a glossary of terms I missed?

I was thinking of a group of devices that can be booted by identical firmware. Best regards Heinrich

[a3f]

Is this meant as a recommendation to mask ROM authors?

[vstehle]

Nit-picking: I think I would prefer "platforms" or even "SoCs" instead of "devices".

[a3f]

I agree that a renaming would clear it up.

[vstehle]

Call of May 22: replace "devices" by "boot firmware" (boot rom or e.g. u-boot spl or later stage) and replace "firmware" by "next boot stage".

[vstehle]

Nit-picking: to address #106 (comment) I wonder if we could rather link the GUID to the firmware "type" or "family" instead.

[xypron]

The target is to be able to create an image that can boot multiple boards. If we use a single GUID, e.g. for U-Boot SPL, this is not possible. Instead the GUID must be specific to the board or SoC specific flavor of the boot stage.

[patrickdelaunay]

So "board type" means one GUID by each supported board reference ?

For example today in TF-A, we are using the same FIP GUID for all boards ussing a STM32MP SoC
(STM32MP15x and STM32MP13x)
=> the recommandation to have a different type GUID by board reference ?

in plat/st/common/include/stm32mp_efi.h

#define STM32MP_FIP_GUID
EFI_GUID(0x19d5df83U, 0x11b0U, 0x457bU,
0xbeU, 0x2cU, 0x75U, 0x59U, 0xc1U, 0x31U, 0x42U, 0xa5U)

the supported board are:
STM32MP157F-DK2
STM32MP157F-DK1
STM32MP157F-EV1
STM32MP135F-DK
.....

=> "creating media that can be booted on a multitude of boards"

For me it is possible only if TF-A BL2 is not board specific
and if the associated FIP not located in the same media than this TF-A BL2
(for example TF-A BL2 in NOR and external media as SD-Card)

as normally the ROM code load the next boot stage = TF-A BL2 on a fixed location (offset or partition) on this media.

[a3f]

@patrickdelaunay for the EV, you should place your FIP into the eMMC boot partition after the TF-A, so you can use the exact same image on eMMC user area across boards. For the DKs, where boot is from SD-Card exclusively, there's no way with current TF-A to use the same TF-A BL2 across all boards (e.g. memory parameters are hardcoded). For those, you need a different image per board anyway, so using different GUIDs for SSBL serves no purpose IMO.

[etienne-lms]

To help defining such a boot image GUID, maybe UUID namespace could help. EBBR would define a GUID namespace and platform to derive their compatible platform string names in that name space.

[vstehle]

Is this meant as a recommendation to mask ROM authors?

I think it is.

This is the continuation of "The platform should locate firmware by searching the partition table for the partition(s) containing firmware" for the specific case of GPT.

[xypron]

Is this meant as a recommendation to mask ROM authors?

This depends on the software that is reading firmware placed on a partition. On some devices the mask ROM may directly read from SD-card or eMMC. On other systems there may be an intermediate boot stage on flash or PROM.

[daniel-thompson]

How does this PR interact with the existing EBBR recommendation that firmware be stored in a filesystem rather than in raw partitions (and further offers a means to locate firmware within ${ESP}/FIRMWARE)?

Using the ESP filesystem to locate firmware was intended to describe the ideal mask ROM behavior because makes it much easier to author media that can boot multiple platforms when compared to having to add may GPT partitions.

I think the text that requires GPT UUIDs to be unique-per-platform should also acknowledge that the existing recommendation is preferred.

[xypron]

How does this PR interact with the existing EBBR recommendation that firmware be stored in a filesystem rather than in raw partitions (and further offers a means to locate firmware within ${ESP}/FIRMWARE)?

Using the ESP filesystem to locate firmware was intended to describe the ideal mask ROM behavior because makes it much easier to author media that can boot multiple platforms when compared to having to add may GPT partitions.

Reading a file system requires a large mask ROM and implementing a file system is error prone. That seems to be why several vendors load from a partition (e.g. SiFive, Microchip, StarFive).

I think the text that requires GPT UUIDs to be unique-per-platform should also acknowledge that the existing recommendation is preferred.

Makes sense.

[xypron]

Currently U-Boot SPL loads main U-Boot by partition number (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION), MBR partition type (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE), or sector (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET). The limits on U-Boot SPL may be so tight that a FAT file system cannot be added to the configuration.

[a3f]

Currently U-Boot SPL loads main U-Boot by partition number (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION), MBR partition type (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE), or sector (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET). The limits on U-Boot SPL may be so tight that a FAT file system cannot be added to the configuration.

I saw this with U-Boot support for Rockchip and I don't get it to be honest. Why can't main U-Boot just be located directly after the SPL and the SPL would boot whatever follows it? That moves the onus onto the BootROM. That's what barebox does for instance on Rockchip, i.MX and others.

[trini]

Currently U-Boot SPL loads main U-Boot by partition number (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION), MBR partition type (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE), or sector (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET). The limits on U-Boot SPL may be so tight that a FAT file system cannot be added to the configuration.

I saw this with U-Boot support for Rockchip and I don't get it to be honest. Why can't main U-Boot just be located directly after the SPL and the SPL would boot whatever follows it? That moves the onus onto the BootROM. That's what barebox does for instance on Rockchip, i.MX and others.

Perhaps a link to how barebox's prior stage loader knows where to find the main stage would be helpful. But for example, some systems (ROMs) say that you can have a loader from between X and X + 256kB, and again at (X+256kB) to (X+256kB+256kB) for redundancy so you can't just start at X and write two stages of loader that exceed 256kB, which is the initial reason for some of those variables (mirroring of the NAND variables for SPL at 256kB offset, not overwriting redundant locations, then U-Boot itself after the final redundant locaiton).

[a3f]

Perhaps a link to how barebox's prior stage loader knows where to find the main stage would be helpful.

barebox prebootloader loads itself again from the boot medium at the same offset itself was located at. On second run, it detects that it runs e.g. from DRAM or in EL3 and thus skips init and extracts itself.

How this "same offset" is determined differs by SoC. Sometime BootROM provides it, sometimes HW is consulted (e.g. eMMC boot partition) or algorithm to find first valid image is reimplemented. That code would be required anyway to implement the barebox_update handler.

Of course, U-Boot supports more platforms and some may not lend itself to this, but e.g. on Rockchip, the BootROM writes to SRAM where it was booted from, yet the default way to boot with U-Boot is AFAIK from a fixed partition for main U-Boot.

But for example, some systems (ROMs) say that you can have a loader from between X and X + 256kB, and again at (X+256kB) to (X+256kB+256kB) for redundancy so you can't just start at X and write two stages of loader that exceed 256kB, which is the initial reason for some of those variables (mirroring of the NAND variables for SPL at 256kB offset, not overwriting redundant locations, then U-Boot itself after the final redundant locaiton).

These systems are not GPT-partitioned and the goal of the PR of running the same image on different platforms will likely not be feasible on them anyway. I think it's worthwhile to nudge silicon vendors into allowing multi-platform images by hardcoding GPT partition type UUIDs instead of fixed offsets. But once we have BootROMs looking up a partition with some specific SoC-unique UUID, the whole boot firmware should go on there (and then continue booting with EFI/bootloader spec/etc.). Example of how it shouldn't look like IMO is the stm32mp1. BootROM looks for fsbl1 partition and then first stage bootloader looks for ssbl partition and AFAIK, fsbl1 partition is size checked, so you can't just place both into the same partition and be done with it. Fortunately, our projects uses eMMC, so we need no boot firmware at all in the MMC user area, but for those having to use SD-Cards, switching to UUIDs instead of partition names alone won't help.

[xypron]

@trini A boot ROM typically will only load as much as fits into static RAM (or cache). So we cannot expect it to load main U-Boot. SPL will have to take care of loading the rest.

@a3f Using the same partition type GUID for SPL and main U-Boot but using an offset for main U-Boot is not contradicting the suggestion in this PR. If that GUID is built into SPL, it does not require any support from the Boot-ROM to find the partition.

[a3f]

Using the same partition type GUID for SPL and main U-Boot but using an offset for main U-Boot is not contradicting the suggestion in this PR. If that GUID is built into SPL, it does not require any support from the Boot-ROM to find the partition.

I still think conflating the two is confusing. My suggestion would be something like this:

Whereever possible, SoC mask ROM shall be configured to boot from a dedicated boot medium
containing all of the boot firmware up to and including the EFI loader.                        

When dedicated boot storage is unavailable, SoC mask ROMs booting from GPT-partitioned media
should use the partition type GUID to identify the partition with the first stage bootloader.
The same Partition Type GUID shall not be reused across SoCs for which a common
first stage bootloader is not feasible.

For cases where the initial boot medium can't physically fit all boot stages up to the
EFI loader firmware, lookup of the next boot stage from GPT-partitioned media should also
happen via Partition Type GUID. The partition type GUID shall not be reused across devices
for which a common second stage bootloader is not feasible. 

In any case, no stage of boot firmware shall enforce size limits on GPT partitions,
but loaded image size may be truncated according to the size of available RAM.

What do you think? I see there's a call about this today and I'll try to join.