[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Feedback from the community -> ARM

On 2021.06.14 11:14, Arnd Bergmann wrote:
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).

Not really.

You can load everything from a standard FAT32 EFI System Partition (ESP), as least on the Raspberry Pi 4, which allows you to create media that is 100% UEFI compliant from the get go (no need for special partitions or anything) and also has the benefit of allowing you to install vanilla Debian using the same media for the target and the source (without even having to do any extra gymnastics for reboot), which can be a hugely beneficial thing on SBCs where connectivity might be limited or where users may not have the luxury of being able to afford 2 media.

As detailed at [1], here is the overview of the entire installation process:

> Create a GPT ESP (EFI System Partition) onto an USB, extract the
> netinst.iso content there, add the latest Raspberry PI UEFI firmware
> and proceed to a standard Debian networked installation. That's it!

And by the way, this method of installing Debian from a single media by leveraging the ESP is something that's also frequently used on x86 UEFI based PCs, so there's really nothing "custom" about that method, apart from the fact that you need to sprinkle a couple extra files besides the extracted ISO content.

As you still need device specific boot media,

Not really. If RK3399 supported picking up its proprietary blobs from ESP (it's not there yet, but it does support reading them from special GPT partitions), then you could create a single media that could install Debian on both RK3399 and BCM2711.

And when I am suggesting that vendors provide UEFI support, ensuring that the platform reading custom blobs from the ESP is also part of what I have in mind, because if you do that, then I don't think the "But it still needs device specific boot media" is receivable.

Of course, it may require distro maintainers to shift from the idea that "people should only use DD when writing ISOHybrids". But then again, considering that the whole point of UEFI was to make booting possible from a simple media content extraction to a FAT32 partition (and even for ARM there are simple ways [2] to work around the 4 GB FAT32 limitation, if your worry is that you may have a >4 GB file on your ISO), this method should always have been something that image creators need to consider, along with some awareness that DD mode is not always the panacea that it's cracked up to be, as it can be very problematic for Windows users [3].

it does not solve the problem that
BBR tries to address by asking for UEFI support in the boot

I disagree. The Pi 4 UEFI installation process demonstrates that we can get pretty darn close to a universal Debian installation process from vanilla ARM64 ISOs, where all you'd need to do to install on this or that platform is drop a couple extra files into your ESP.

This also solves the rather important issue of Debian having to provide custom images with non-free blobs, whereas you can now just ask users to pick these files themselves and use a simple file copy operation to add them.

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

If you're still thinking in terms of DD application of a vanilla Debian ISO then yes. But if you are thinking in terms of extracting ISO content onto FAT32 to create UEFI bootable media, then I'd say you get fairly close to "board agnostic boot media" if the SBC/SoC is designed to pick the additional content it needs from a standard UEFI partition and the user just has to file copy these missing elements.

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

Just a note that I tried to informally see if the Raspberry Pi Foundation would be considering bumping the size of the SPI flash on the Pi 4 to accommodate the UEFI firmware (which has the downsize of always being rather large. Even compressed, the Pi 4 one is larger than 2 MB), but they didn't seem to be that receptive to the idea. If anything, they went the other direction and removed on of the 2 SPI flash chips they had on newer revisions.

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.

Or, like the Pi 4 does, be capable of storing and retrieving the UEFI firmware and other proprietary blobs from the ESP...



[1] https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839
[2] https://github.com/pbatard/uefi-ntfs
[3] https://github.com/pbatard/rufus/wiki/FAQ#Why_doesnt_Rufus_recommend_DD_mode_over_ISO_mode_for_ISOHybrid_images_Surely_DD_is_better

Reply to: