[RISC-V][tech-os-a-see] Recommendation for identifying partition with firmware to be loaded from SD-card

Aaron Durbin adurbin at rivosinc.com
Mon May 1 16:47:33 CEST 2023


On Mon, May 1, 2023 at 8:46 AM Heinrich Schuchardt <
heinrich.schuchardt at canonical.com> wrote:

> On 5/1/23 16:31, Aaron Durbin wrote:
> > Hi,
> >
> > On Mon, May 1, 2023 at 8:26 AM Heinrich Schuchardt
> > <heinrich.schuchardt at canonical.com
> > <mailto:heinrich.schuchardt at canonical.com>> 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.
> >
> >
> > Who is loading the firmware that is identified by a GUID?  And how does
> > that tie into Linux distros? I don't see anything wrong w/ the
> > recommendation, but I didn't completely follow which piece of software
> > is loading firmware and how the GUID reduces the problems. Also, is this
> > "SoC specific partition type GUID" unique per SoC? Or is it expected to
> > be a global GUID?
>
> Booting firmware starts at boot ROM which may either directly load a
> piece of software from SD-card or may load a piece of software from
> flash which in turn will load the next step boot loader from the SD-card.
>
>  From the view of a distro it is best if each board uses a separate
> GUID. This allows to add multiple U-Boot versions (or other boot
> software) on the same SD-card.


OK. So then you want the firmware itself that is chainloading programs to
use SoC-specific GUIDs. Is that correct?


>
> Best regards
>
> Heinrich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.denx.de/pipermail/u-boot-custodians/attachments/20230501/92e40a03/attachment-0001.htm>


More information about the U-Boot-Custodians mailing list