Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Fri, 5 May 2023 at 12:52, Pete Batard <pete@akeo.ie> wrote:
> On 2023.05.04 14:16, James Addison wrote:
> > Yep, and for those situations, that's a point in favour of the third
> > "System Table Selection" value that I failed to mention:
> > "ACPI+Devicetree".
>
> Indeed, the firmware provides that that option as well.
>
> > I'm cautious about recommending it, given an understanding that
> > enabling ACPI could increase the amount of non-free code (ACPI Machine
> > Language, in particular) that may run on the system as a result.
>
> I think with current CPUs (especially on the x86 side with Management
> Engines as well as proprietary blobs), we're alas way past the point of
> being able to prevent non-free code from running.
Somewhat agree, yep - although I think that in this case, there should
be various paths available (u-boot, EDK2, ACPI/DT), and if possible
I'd like to understand what is the approach that provides the most
compatibility and free software support with the fewest moving parts.
To me, the reliability and human-time cost savings from simpler, more
open and straightforward systems outweigh many other factors,
especially over the long term.
That's partly the reason I've been wondering about the power
consumption and operating-system-compatibility questions: as I
understand it, those were key reasons that server hardware vendors had
a preference for ACPI when determining the server standards in the
mid-2010s, and so a few years since then, it could be helpful to
figure out whether those continue to make a difference, and how
Devicetree/FOSS driver implementations compare.
> The Raspberry Pi SoC has also some very non-free code running that
> executes prior to the running of the UEFI firmware and also in parallel
> to the UEFI firmware and OS. There's basically a Management Engine
> running on the GPU, which, among other things, provides a mailbox that
> the UEFI firmware uses to retrieve or set hardware configuration data.
Yep, I've still got quite a lot to learn about that, I think.
> On the other hand in this specific case, though I understand you're
> speaking in a more general manner about ACPI usage, the whole ACPI blob
> generation comes entirely from open source code.
I think that's great, and I've had a good experience with EDK2 +
Devicetree. My concerns about ACPI are basically that it seems like a
less-readable, larger-surface-area standard with more opaque processes
surrounding it. But I'm not an expert.
> As far as I'm concerned, the main reason I wouldn't advocate ACPI +
> Device Tree is that it can create user confusion as to what is really
> being used behind the scenes. A bit like when PC end-users enable Legacy
> boot in their UEFI settings and end up installing their OS in Legacy
> mode on a UEFI capable system, then find themselves in a situation where
> they want to use UEFI features but can't.
Getting slightly further off-topic, but for my own education: what is
an example of a UEFI feature that a user might want to use?
(to my mind, most of my preferences are: I want to use a standard,
easily-obtained installer, for each system install to be
straightforward and for the system to boot, for each system's devices
to function correctly, and for those to occur while minimizing the
amount of extraneous runtime code and I/O (roughly in that order of
precedence, and with FOSS practices helping a lot to achieve and
maintain those in the long-term). perhaps ranty, but it's intended to
explain why I don't love standards that include unusual and/or
unproven quirks, and binary blobs)
> Also, again, since part of our goal has been to promote the emerging
> SBBR standard (because we think it should ultimately help making
> installation of various OSes on par with what is the case for x86 based
> PCs, where you can pretty much just create a universal boot media as
> well as have the OS install and use unified boot loaders, rather than
> force users to concern themselves about the low-level system specifics
> of their system, and play with yet another custom version of u-boot),
> and SBBR made the choice to go with ACPI only rather than
> ACPI+DeviceTree, we decided to propose ACPI+DeviceTree as a means not to
> restrict user choice for people who want to use both, but knowing that
> it's not something we really want to officially support.
Yep, that makes sense and your decision-making logic is sound.
If I were to imagine a two-line chart of device and hardware support
over time, with one line each representing the ACPI and Devicetree
approaches, then based on this standardization and industry backing, I
would expect ACPI to be the upper line for some duration of time
(decade?) until the point at which the drawbacks and disadvantages of
the extraneous functionality and complexity that I sense (but can't
really confirm, yet) outweigh the industry momentum placed behind it.
And I think that's a shame, because if the same effort and backing had
been placed behind a simpler, more open and maintainable approach
(namely the other line, Devicetree) then I think that overall
ecosystem cost savings and user/consumer respect improvements could
have been increased -- and that _should_ be good business. That's not
to say there aren't risks - if I were a strategic decision-maker with
investments/alignment in maintaining revenue models for some of the
affected technologies, processes and staff then I would probably feel
differently. Ultimately it feels like a question of time, though, and
delaying progress based on revenues and partnerships from a margin of
unnecessary cost passed on to purchasers feels wrong.
> > Slightly off-topic: do you know of cases where ACPI has helped a
> > vendor to adapt to shifting operating system interfaces or achieve
> > significant energy-usage savings?
>
> I'm afraid I'm ill placed to discuss ACPI specifics, as, despite having
> contributed one or two patches here and there to the Raspberry Pi UEFI
> firmware ACPI bindings, my knowledge of ACPI is very limited.
>
> With regards to adapting to OS interfaces my guess, even if it seems to
> be at odds with the Linux kernel efforts of the past few years, is that
> even with its limitations and constraints it was probably better to go
> with a well established and relatively well supported implementation
> that can effectively be shared with multiple OSes, rather than ask
> hardware manufacturers to juggle with multiple implementations when
> providing a functional implementation that complies with a specific
> standard, especially a new one. So I would say that it was probably
> decided that, since vendors were expected not to go with a standard that
> would force them to "duplicate" some work, the burden of having to
> support ACPI and only ACPI would be shifted to the OS folks, even if it
> went against the direction that Linux had already been taking at that
> stage...
My understanding is that the Linux development community has (and
continues to) pay the cost of maintaining ACPI compatibility, while
Devicetree (also with cost to support and develop) appears
well-supported across multiple architectures and appears (again, based
on very limited experience of mine) to be quite easy to work with,
configure and (re)deploy.
> But again, this is pure speculation on my part, and I can't tell if
> ultimately picking up ACPI only will actually help vendors to go with
> SBBR and, hopefully, better adapt to shifting OS interfaces, since the
> idea is that OSes should also strive to follow SBBR... even if that
> means, in the case of Linux, having to support ACPI alongside Device
> Tree. No idea about energy savings though.
>
> > I think that understanding some of
> > those could help to begin to address gaps that Debian/Linux/other
> > components have.
>
> I suspect that if you post your question to the edk2-discuss mailing
> list [1], which is frequented by the same developers as edk2-devel and
> therefore should be seen by people who are very knowledgeable about
> ACPI, you might be able to get insightful answers to your question.
I think there's a good chance that I've misunderstood a bunch of
important details already, so I'll take some more time to try to
figure out what those are and learn the landscape a little better --
and figure out whether there are problems that I can and want to help
to solve in that area -- before participating, but thank you.
Thanks,
James
Reply to: