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 <[email protected]> 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 <[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? > > > > > > 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 > > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
