[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