<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 1, 2023 at 8:46 AM Heinrich Schuchardt <<a href="mailto:heinrich.schuchardt@canonical.com">heinrich.schuchardt@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/1/23 16:31, Aaron Durbin wrote:<br>
> Hi,<br>
> <br>
> On Mon, May 1, 2023 at 8:26 AM Heinrich Schuchardt <br>
> <<a href="mailto:heinrich.schuchardt@canonical.com" target="_blank">heinrich.schuchardt@canonical.com</a> <br>
> <mailto:<a href="mailto:heinrich.schuchardt@canonical.com" target="_blank">heinrich.schuchardt@canonical.com</a>>> wrote:<br>
> <br>
>     Linux distributions are interested in providing a single image which<br>
>     enables a high number of boards to boot. This is simple if the boot<br>
>     firmware (EDK II or U-Boot) is installed on flash.<br>
> <br>
>     For boards that expect to load a boot loader like U-Boot from an SD-card<br>
>     it is necessary that the firmware locations for different boards<br>
>     on the SD-card don't collide.<br>
> <br>
>     When loading from SD-card or eMMC the sector at which the binary<br>
>     starts has to be identified. The following has been implemented:<br>
> <br>
>     - start from hard coded sector number<br>
>     - load file from FAT file system<br>
>     - load from given partition number<br>
>     - load from partition with boot flag set (MBR partioning only)<br>
>     - load from partition with specific type GUID<br>
> <br>
>     Loading by partition type GUID seems the most appropriate to avoid<br>
>     collisions between the firmware for different boards.<br>
> <br>
>     Often firmware is separated into multiple parts due to firmware<br>
>     restrictions, e.g. U-Boot SPL and main U-Boot (e.g. as .itb file).<br>
> <br>
>     Here the same considerations apply. Using a partition type GUID to<br>
>     identify further firmware parts to be loaded is best suited to<br>
>     avoid collisions.<br>
> <br>
>     I would suggest to add a recommendation to the EBBR specification<br>
>     to use SoC specific partition type GUIDs to identify firmware to<br>
>     be loaded from SD-card.<br>
> <br>
> <br>
> Who is loading the firmware that is identified by a GUID?  And how does <br>
> that tie into Linux distros? I don't see anything wrong w/ the <br>
> recommendation, but I didn't completely follow which piece of software <br>
> is loading firmware and how the GUID reduces the problems. Also, is this <br>
> "SoC specific partition type GUID" unique per SoC? Or is it expected to <br>
> be a global GUID?<br>
<br>
Booting firmware starts at boot ROM which may either directly load a <br>
piece of software from SD-card or may load a piece of software from <br>
flash which in turn will load the next step boot loader from the SD-card.<br>
<br>
 From the view of a distro it is best if each board uses a separate <br>
GUID. This allows to add multiple U-Boot versions (or other boot <br>
software) on the same SD-card.</blockquote><div><br></div><div>OK. So then you want the firmware itself that is chainloading programs to use SoC-specific GUIDs. Is that correct?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best regards<br>
<br>
Heinrich<br>
</blockquote></div></div>