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