Recommendation for identifying partition with firmware to be loaded from SD-card

[Michal Simek]

On 5/4/23 16:54, Heinrich Schuchardt wrote:
> On 5/4/23 13:39, Michal Simek wrote:
>>
>>
>> On 5/1/23 16:26, Heinrich Schuchardt wrote:
>>> 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.
>>>
>>> For boards that expect to load a boot loader like U-Boot from an SD-card
>>> it is necessary that the firmware locations for different boards
>>> on the SD-card don't collide.
>>>
>>> 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
>>> - load file from FAT file system
>>> - load from given partition number
>>> - load from partition with boot flag set (MBR partioning only)
>>> - 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.
>>>
>>> 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.
>>>
>>> Please, provide your feedback.
>>
>> Isn't this very similar to effort which Andre presented at Fosdem 2019?
>>
>> https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/attachments/slides/3342/export/events/attachments/one_image_to_rule_them_all/slides/3342/simage.pdf
>>
>> Thanks,
>> Michal
> 
> Thanks Michal for the pointer. We are talking about the same topic. The question 
> that was not resolved up to now is how we can avoid conflicts between the U-Boot 
> binaries of different SoCs stored on the same medium. This is where I propose to 
> use GUID partition types.
> 

Xilinx/AMD SoC are using boot.bin files stored in fat partitions. Bootrom 
doesn't do difference if it is fat or ESP. And with Xilinx bootloader boot.bin 
contains U-Boot inside. It means we are talking about one file allocated for 
Xilinx boards. If boot.bin is not found it looks at boot0001.bin, etc.
It means for our SOCs we just need to add these files there and that's it.
For supporting different boards with board identification we have also solution 
for it.
If this targets SPL (not Xilinx first stage bootloader) on ZynqMP(only) then 
u-boot.itb is expected with TF-A/U-Boot/DT inside. File name can be tuned of 
course. I think by default we only support fat/esp only. And for additional 
support via GUID we likely hit issue with SPL size which is in OCM.
That's why I would simply use with self contained boot.bins on ESP which is 
recommended solution anyway.

Thanks,
Michal