On Wed, 2 Sep 2020 at 14:10, Grant Likely <[email protected]> wrote:
> > > 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. > On the RPI4, when you install Linux or Windows, don't you install also the FW? In that case, there is no reconfiguration but re-flashing? Or is it that the UEFI config tables contain both DT and ACPI? > > 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 > -- 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
