On 02/09/2020 11:42, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 02:35:54PM +0300, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 14:26, Peter Robinson <[email protected]> wrote:
On Tue, Sep 1, 2020 at 12:21 PM Grant Likely <[email protected]> wrote:
On 01/09/2020 12:06, Heinrich Schuchardt wrote:
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.
The crux of the matter is that platform X described via ACPI cannot be
assumed to be the same as platform X described via DT. Peter points
out the device naming changes due to different enumeration order, but
there are many other issues (NUMA topology, RAS features etc). So
there can be no guarantee whatsoever on OSes that are able to support
both descriptions that any OS or HW configuration state can be
preserved across a switch from ACPI to DT or vice versa.
I understand how on the face of it, permitting both to coexist might
seem like the easiest approach from the platform vendor POV, but I
think this is a mistake. Making it the system's job to choose one
description or the other removes any ambiguity, and therefore prevents
problems. I understand how OSVs like MS entering the space that has
historically been dominated by DT are eager to make the switch
seamless for them, but doing so creates problems for Linux, so I would
prefer not to go down this path.
To be honest I'm inclined to the view that it is having a single
product supporting both DT and ACPI is what creates the problems
for Linux. There are two options and the best option may well
be different for different Linux kernels: stable kernels probably want
ACPI until the board is very mature and linux-next and vendor kernels
probably run best in with device tree[1]. Somewhere in the middle there
is a cross-over point.
I'm not clear why making the OS bootloader choose the h/ware
description instead of the system providing a user-controlled choice
will makes this problem worse (or better).
More than that however, to really understand things I'd like to more
clear about the type of products that are envisaged that would possess
both ACPI and DT descriptions. It hard to understand how an true
embedded product would need to do this! Are we concerned about reference
software shipped by SoC, SoM and dev board vendors or does it go deeper
than that?
The Raspberry Pi is a great real world example. Linux support for the PI
is mature with DT and makes heavy use of overlays to modify the
configuration of the platform. For the foreseeable future DT will remain
the preferred RPi system description. At the same time there has been a
lot of activity to bring up ACPI on the Pi to support Windows and VMWare
ESXi. The EDK2 port to the pi carries both DT and ACPI descriptions.
Windows, Linux and ESXi boot out of the box. Linux chooses DT by
default. Windows and ESXi use ACPI. The user doenn't need to reconfigure
firmware to run one or the other.
g.
Daniel.
[1] If they don't then the product shouldn't bother supporting DT at
all ;-)
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
