On 2021.06.12 23:15, Andrew M.A. Cater wrote:
On Sat, Jun 12, 2021 at 11:04:35PM +0100, Wookey wrote:On 2021-06-12 11:57 +0100, Pete Batard wrote:As a matter of fact, starting with RPi3, the Raspberry Pi has been an official EDK2/UEFI platform for more than 2 years now.... 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").We have embraced UEFI and if it's available the installer should use it.
Yes, and I appreciate your help with that.But from my perspective, it was quite a struggle to get a small patch, that was critical for proper UEFI installation, to be looked into by Debian folks with some priority. And it's not until you stepped in that things moved forward. Plus it appears that we were also lucky that the Bullseye release was delayed, else that patch, and thus the ability to install Bullseye on the Pi 4 in UEFI mode, may not have made it into the release.
Granted we also should have logged a bug for that issue as soon as we picked it up, so we have to share part of the blame on this one. But the delays in processing #985956, even though we tried to bring attention over and over again to the fact that this very negatively affected one of the rare UEFI installation of Bullseye on ARM64, on what has to be the current most widespread system for that arch, was a bit concerning. Especially, it is not the first time we've seen what I would qualify as extended delays in trying to get showstopping UEFI patches looked into. As a matter of fact, I eventually gave up trying to get the necessary Pi4 network patches backported into Debian 10 (#950578), because even though we did submit a working patch from the get go, it took 3 months (!) to actually get someone on the Debian side to look into it, only to then tell us to just go re-do that patch, which is not what I would qualify as a viable mode of operation.
So, at the risk of being controversial, it doesn't seem to me like everybody in the Debian world has been that willing to embrace UEFI. Or if they do, then not everybody appears to have recognized the importance of being able to provide Debian in UEFI mode on what has to account for the most popular ARM64 platform. And I could point to further evidence of this when I also brought the idea on this list that, maybe, it was time for Debian to start looking into moving away from using good old uboot or similar for distributing special installable images for platforms like the Pi not that we have a full blown UEFI, as this very idea seemed to irk a few people (which, to be fair, may not have been directly affiliated with Debian).
But regardless of this, my remark was aimed more at the topic at hand which should be what feedback Debian may want to convey to the ARM community, and especially the ARM platform manufacturers, and therefore goes beyond than just the Raspberry Pi platform.
In short, I would reiterate that, in light of the headaches caused by all the other approaches, and especially a requirement that still seems to boil down to providing custom images (in part because of custom boot methods as well as proprietary blobs, which I don't realistically see as going away) the feedback Debian should provide to ARM vendors is that, if the latter want better cooperation with Linux distros, then they should put the onus on releasing a working UEFI firmware for their platform, especially as it's been demonstrated that, even for an SBC as quirky and as ill-suited for it as the Raspberry Pi (and that was part of the point of the whole exercise), it is not that difficult to achieve.
Regards, /Pete