On 01.09.20 13:21, Grant Likely 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 (?)
OpenBSD: https://www.openbsd.org/arm64.html "Both device trees and ACPI are supported." FreeBSD supports both, cf. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246552 NetBSD: https://www.netbsd.org/releases/formal-9/NetBSD-9.0.html "Single GENERIC64 kernel supports ACPI and devicetree based booting" Best regards Heinrich > 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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
