[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

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:

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.



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

Reply to: