On Tue, Sep 1, 2020 at 12:21 PM Grant Likely <[email protected]> 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/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
