W dniu 1.05.2023 o 16:26, Heinrich Schuchardt pisze:

Linux distributions are interested in providing a single image which enables a high number of boards to boot. This is simple if the boot firmware (EDK II or U-Boot) is installed on flash.

1-4MB of SPI flash should be mandatory for all devices. Or use of eMMC boot partitions.

When loading from SD-card or eMMC the sector at which the binary starts has to be identified. The following has been implemented:

• start from hard coded sector number

Please don't. Or choose something far from end of GPT data. This way it can be covered with "BIOS boot" partition.

• load file from FAT file system

On GPT disk you mean 0700 (Microsoft FAT) or EF00 (EFI System) partition?

• load from given partition number

Please don't. User may want to use same disk image on several systems. And vendors would choose 1st/2nd/3rd just because they can. Also not every partitioning tool is fine with larger numbers.

• load from partition with boot flag set (MBR partioning only)

GPT partitions can have several flags set. ChromeOS used it to select which kernel/rootfs to use as A/B.

• load from partition with specific type GUID

Loading by partition type GUID seems the most appropriate to avoid collisions between the firmware for different boards.

Who would assign those GUIDs? How often random vendors will choose already existing one? There are several SBC vendors not caring at all about anything other than sales.

On Mon, May 01, 2023 at 04:26:25PM +0200, Heinrich Schuchardt wrote:

<snip>

Often firmware is separated into multiple parts due to firmware restrictions, e.g. U-Boot SPL and main U-Boot (e.g. as .itb file).

Here the same considerations apply. Using a partition type GUID to identify further firmware parts to be loaded is best suited to avoid collisions.

I would suggest to add a recommendation to the EBBR specification to use SoC specific partition type GUIDs to identify firmware to be loaded from SD-card.

EBBR currently recommends new devices load such firmware from the EFI System Partition and provides guidance on using the directory structure to avoid collisions: https://arm-software.github.io/ebbr/index.html#firmware-partition-filesystem

This guidance describes "ideal" ROM-code and AFAIK is currently aspirational since EBBR has not yet been around long enough to have any impact on what SoC vendors ship in their ROM code.

Using ESP is optional and certainly there is no guidance in the spec about selecting GUIDs to avoid collisions (e.g. don't use the same GUID in next-gen chips that require different firmware).

IMHO guidance w.r.t. GUID colision avoidance is only useful if we believe *future* SoC vendors will be unable to follow the current prefer-to-use-ESP guidance (because anti-colision guidance will likely take just as long to be implemented in SoC ROM code as prefer-to-use-ESP guidance).

Daniel.