Re: Feedback from the community -> ARM
On Sun, Jun 13, 2021 at 01:42:55AM +0100, Pete Batard wrote:
>
>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 AFAICS what you're seeing is a severe lack of volunteer time to do
some things in Debian. I've been one of the more active Debian arm
porters in recent years, but I've moved on to other things and been
swamped with things like shim and grub security work in my "spare"
time for the last year or so. I'm also busy with a new job that (so
far) has very little to do with the Arm world, so I've not been able
to spend work time to pick up on some of these issues where prveiously
I might have done.
While this stuff is important for you and others, I'm afraid that
doesn't necessarily make it top priority for volunteers already
overloaded with other projects. That's not a lack of will to help,
it's simple logistics. :-( We need to get more people involved to
help, and that's often a struggle.
>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).
As a Debian UEFI team person, I'm *really* happy that finally we have
an affordable platform that might work sensibly like this. As Marcin
says: if anything, our arm64 port has expected UEFI from the
get-go. There are still remnants of this assumption in d-i if you go
looking, where we don't work well enough on other platforms.
However, one of our biggest issues has been the ridiculously,
*appallingly* over-diverse Arm ecosystem with vendors continuing to
push special-snowflake SBCs that all need special consideration just
to do the simple basic things. It's batshit insane. On reflection,
that mess was one of the reasons why I changed jobs. It was causing
enough stress that I had to get away from it.
>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.
+1000
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
as meaning someone who's only ever written one device driver." -- Daniel Pead
Reply to: