XPost: linux.debian.ports.arm

Hi James,

Since we're getting off-topic, and I don't think there's much of this
reply that's going to be relevant to it, I dropped the CC to bug 1035392.

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.

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.

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.

Perhaps there could be counterbalancing functionality benefits and/or energy-usage savings... even then I'd recommend proceeding cautiously.

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.

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.

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

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.

Regards,

/Pete

[1] https://edk2.groups.io/g/discuss

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)