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

Re: Feedback from the community -> ARM

On 2021.06.12 09:29, Paul Wise wrote:
Will this be added to edk2-platforms?


It already has:


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").



Reply to: