Re: Feedback from the community -> ARM
On 2021.06.12 09:29, Paul Wise wrote:
Will this be added to edk2-platforms?
https://github.com/tianocore/edk2-platforms/
It already has:
https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4
The Raspberry Pi 4 UEFI firmware has been an official EDK2
implementation for some time...
As a matter of fact, starting with RPi3, the Raspberry Pi has been an
official EDK2/UEFI platform for more than 2 years now.
As to libre replacements for the proprietary blobs, while this is of
course a desirable effort that I too hope can come to fruition, it
wouldn't change much in terms of booting a generic kernel from UEFI
since those blobs intervene way sooner than that. Even with libre
versions of those the boot handover process on the Pi would still be
blobs -> TFA -> UEFI -> kernel, which is how you want it when you do
have the luxury of an ARM64 platform with a full blow UEFI firmware.
Also, AFAIK, coreboot still has to use proprietary blobs to bring up RAM
and other stuff that intel/AMD don't want to open up, which they've
pretty much come to terms with, so I'm not sure using coreboot as an
example to follow, for doing away with proprietary blobs, is that
effective. Similar to coreboot, the UEFI firmware we have on the Pi 4
should actually be construed as a way to keep the annoying proprietary
stuff away, and instead provide an Open Source implementation for one of
the rare well established industry standards that the mainline kernel,
and by extension Debian, could actually rely on to *simplify* their
operations.
I mean, isn't the goal of being able to stop chasing after yet another
custom implementation, in order to support this or that ARM platform,
one of the points being sought from this discussion? Because if that is
the case, then, instead of demanding that ARM SoC/SBC manufacturers do
away with proprietary blobs, which is unlikely to happen, Debian could
do itself a favour by embracing UEFI support for platforms that have it
and at the same time try to set a clear delimiter of responsibilities
("ARM manufacturers, if you provide a working UEFI implementation for
your platform to take care of the early boot code/custom kernel
headaches, then we'll see what we can do to make our distribution work
on it").
Regards,
/Pete
Reply to: