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
firmware.
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
those.
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...
Regards,
/Pete
[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: