On 01/09/2020 12:06, Heinrich Schuchardt wrote:
On 9/1/20 12:45 PM, Grant Likely wrote:
Early in EBBR discussions the decision was made that firmware should not
provide both DT and ACPI at the same time. The reasoning had been that
we didn't want to encourage 'hybrid' approaches where the OS tries to
consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that
requiring a boot-time switch to select either DT or ACPI is a support
issue for OS vendors. They would rather see ACPI (or DT) always turned
on if it is an option and the OS can choose to use it or not.
Which OS vendor are your referring to?
Why does that OS vendor not implement both ACPI and DT support to
encompass as many devices as possible?
Sure; in concrete terms, this is what I see among the major OSes:
Linux: support both; consumes DT by default. (some distros change the
preference; "acpi=force" forces kernel to use ACPI instead) [1]
BSD: Both (?)
Windows: ACPI only
VMware ESXi on Arm: ACPI only
What would we expect to happen if the ACPI and DT content are not
equivalent?
Then the OS would get the functionality of whichever system description
it chose. The experiments with ACPI-only OSes on Arm SBCs have shown
that there is interest in supporting the platforms, even if the initial
functionality is reduced due the not all hardware having a usable ACPI
description (lots of reasons for this from hardware design not fitting
nicely into the ACPI model, to lack of bindings, to just hasn't been
looked at yet)
g.
---
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/acpi.c#n201
/*
* Enable ACPI instead of device tree unless
* - ACPI has been disabled explicitly (acpi=off), or
* - the device tree is not empty (it has more than just a /chosen node,
* and a /hypervisor node when running on Xen)
* and ACPI has not been [force] enabled (acpi=on|force)
*/
---
Best regards
Heinrich
Thoughts? Can the exclusive or be relaxed here?
Signed-off-by: Grant Likely <[email protected]>
---
source/chapter2-uefi.rst | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 066fefb..e0e71d6 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -80,18 +80,12 @@ Configuration Tables
A UEFI system that complies with this specification may provide the
additional
tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the
following
+Compliant systems are required to provide at least one of the following
tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or
- a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree
-tables at the same time.
-Systems that support both interfaces must provide a configuration
-mechanism to select either ACPI or Devicetree,
-and must ensure only the selected interface is provided to the OS
loader.
-
Devicetree
^^^^^^^^^^
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
