Could this section be updated in order to reduce the number of different interpretations?
Yes, it can be clarified. As Daniel says, this section is only intended for platforms where there is no other place to store firmware. If the OS and the firmware need to share a logical block device, and there is no way to protect the firmware bits, then this section describes how they can co-exist. e.g., you don't want an OS deployment to accidentally wipe out firmware.
It is preferred and encouraged to have firmware contained entirely in something separate from the main block storage. For example, in eMMC boot areas (separate from the primary area), or on a separate device entirely (SPI flash). I predict that a future version of EBBR will require this and drop the shared storage option entirely because it is necessary to protect against attacks against firmware (replacement or deletion)
g.
Thank you all contributing to this thread!
While most of the points in this thread are self-explanatory and should not need a summary, I want to extract the main points to avoid misinterpretations: 1. Chapters '4.1 Partitioning of Shared Storage' and '4.2 Firmware Partition Filesystem' refer to cases when shared storage is used for OS and firmware images. In this case, the block device needs to be partitioned using GPT and the firmware binaries should be stored in a FAT partition. The folder organization for this partition is described in the '4.2.1 The firmware directory hierarchy' chapter. Ideally, the BootROM should be able to load images from a FAT partition. However, a feature release of the EBBR is likely to drop this option in the future.
2. For scenarios involving dedicated storage, the organization of the underlying storage for firmware falls outside the scope of the EBBR and can be arranged according to the SoC vendor's discretion. This can include options such as offset addressing, without GPT, with MRB, with or without a partition, based on the platform's requirements or limitations.
Could you please confirm that this understanding is correct?
If I recall correctly, on the Arm platform, A-BL1 (BootROM) and A-BL2 are responsible only for loading the images. SCP_BL2 is loaded by BL2 into trusted SRAM and then transferred to the SCP using the MHU protocol and I believe it is followed this way for other platforms also (?). In summary, A-BL1(BootROM) and A-BL2 need to be aware of their next stages to load those images properly: BootROM -> BL2 -> BL31 -> ... | v SCP
If the above summary points are valid, then in the case of a shared device, the BL2 should be able to load the next image(s) (either FIP or BL31) from a FAT partition, I suppose.
Regards, Ghennadi