Re: Feedback from the community -> ARM
On Mon, Jun 14, 2021 at 10:45 AM Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> wrote:
> W dniu 14.06.2021 o 03:22, Paul Wise pisze:
> > On Sun, Jun 13, 2021 at 9:45 AM Marcin Juszkiewicz wrote:
> >
> >> Let me bring the idea on this list that, maybe, it is time for vendors
> >> to start looking into moving away from using good old U-Boot on microsd
> >> or similar to provide on-board SPI flash to store bootloader. So we
> >> could stop distributing special installable images for platforms like
> >> the Pi.
As far as I can tell (please let me know if this has changed), the only
way to get UEFI boot on Raspberry Pi is to load an EDK2 from
a special partition on a bootable drive (µSD or USB). As you still
need device specific boot media, it does not solve the problem that
BBR tries to address by asking for UEFI support in the boot
firmware.
> > Storing boot firmware on the board seems to encourage various
> > sub-optimal things. Fully proprietary bootloaders. GPL violating
> > bootloaders. Bootloaders containing blobs. Bootloaders that are locked
> > down and cannot be replaced at all, especially on mobile. Forks of
> > random snapshots of existing bootloaders.
> >
> > Personally I would go the other way; there should be a standard boot
> > protocol between the SoC boot ROM and later layers of the boot process
> > and vendors should stop shipping any boot firmware beyond the SoC boot
> > ROM, leaving it to OS distributors to package mainline bootloaders
> > that support that protocol.
>
> Whatever allow SBC to have "unpack, connect, install, reboot, use".
>
> Now on-boot-media bootloader can be whatever crap you can imagine.
>
> And still requires maintaining all those /InstallDebianOn/RandomSBC wiki
> pages, tools to generate installer images per board, tools to generate
> bootable images per board etc.
Agreed, it is impossible to have board-agnostic boot media at the same
time as board-agnostic boot ROM unless you have some other place to
store board specific code and data, pretty much by definition. Whether
you store this in eMMC boot-partition, a spi-nor chip, or on-chip flash
doesn't matter too much, but most boards already have at least on of
those. The missing bit that I see is getting board vendors to actually enable
UEFI support in their boot firmware, and storing (all of) it in the boot
partition rather than the eMMC data partition.
Arnd
Reply to: