Bug#1035392: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
[ replying with some re-ordering ]
On Wed, 3 May 2023 at 21:23, Pete Batard <pete@akeo.ie> wrote:
> Obviously, with the idea of not having ARM based device that are
> constrained to a single OS (be it Windows, Linux, BSD or something> else), and considering that Windows and Device Tree don't work together,
> you want to go with a mode of operation that isn't Linux specific,
> which, even if ACPI has its drawbacks, pretty much forces the use of
> ACPI over Device Tree. Else, you have Linux going into the exact
> Microsoft strong-arm tactics that it should strive to avoid...
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".
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.
Perhaps there could be counterbalancing functionality benefits and/or
energy-usage savings... even then I'd recommend proceeding cautiously.
I'm not sure I'm qualified to say much about Debian's compatibility
with other operating systems on the same machine, other than to
mention that I do think it's highly compatible and that that's
something that maintainers, developers and users care about.
> On 2023.05.03 17:29, James Addison wrote:
> > * Perhaps Devicetree is a better default in EDK2 for ARM systems?
> > (that wouldn't solve the root cause, though)
>
> Please note that the reason why the Raspberry Pi UEFI firmware defaults
> to ACPI is so that this ARM device follows the relatively new ARM SBBR
> standard [3], which we (hopefully) expect more and more ARM64 based
> device to follow.
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 think that understanding some of
those could help to begin to address gaps that Debian/Linux/other
components have.
(and to mention why I ask.. I've been reading some of the history[1],
definitions[2], rationale[3], and state-of-support[4] around
DeviceTree and ACPI in Linux, including in relation to ARM servers.
it looks like I have a decade-or-so of history to catch up on there)
[1] - https://lore.kernel.org/linux-arm-kernel/CAOesGMjKeRb=fFJM0MabDihbEiCGM4EqW9D5i_6-RFxTnpB4Qw@mail.gmail.com/
[2] - https://elinux.org/Device_Tree_What_It_Is
[3] - https://www.secretlab.ca/archives/151
[4] - https://www.kernel.org/doc/html/v6.3/arm64/arm-acpi.html
Reply to: