If ACPI was just a description of hardware the market would have rapidly settled on either ACPI or DT.
The key difference is that ACPI is also a byte code exécution engine and that it can provide architecture agnostic methods to be called. This will be awfully complex and costly to pass safety certification with a full scope.
The other issue is that DT also is sometimes a kernel driver parameter source rather than hardware description. So most likely a driver is either a DT or an ACPI driver. Supporting both for a driver is not simple unless proper explicit guidance is available.
As reported recently, some MDIO stuff are not well supported in ACPI. I would argue that not trying to standardize this type of hardware in ACPI would be like having a DT specification without standardized bindings: a recipe for fragmentation nightmare.
In any case to answer your question, a boot flow should be either UEFI/DT or UEFI/ACPI exclusively. A platform can follow one flow for a product and another for another product.
Cheers
Ff
Le mer. 2 sept. 2020 à 12:43, Daniel Thompson daniel.thompson@linaro.org a écrit :
On Tue, Sep 01, 2020 at 02:35:54PM +0300, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 14:26, Peter Robinson pbrobinson@gmail.com
wrote:
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:
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?
Daniel.
[1] If they don't then the product shouldn't bother supporting DT at
all ;-)
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog