On Tue, Sep 1, 2020 at 12:21 PM Grant Likely grant.likely@arm.com wrote:
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
RHEL 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)
Also network and storage interface, possibly others, names often change just due to the way naming//bindings/IDs are handled between the two.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...
/*
- 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 grant.likely@arm.com
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 boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture