On Fri, 19 Sept 2025 at 17:10, Simon Glass <[email protected]> wrote: > > Hi, > > On Mon, 8 Sept 2025 at 15:41, ff <[email protected]> wrote: > > > > > > > > On 8 Sep 2025, at 20:43, Heinrich Schuchardt > > <[email protected]> wrote: > > > > > > > > > > ff <[email protected]> schrieb am Mo., 8. Sept. 2025, 19:27: > > Dear fellow firmware aficionados, > > > > Static ACPI has been adopted by Mercedes and other silicon vendors to: > > - meet the safety requirements > > - stay away from DT lifecycle issues > > - leverage chiplet and CXL bindings > > - truly multi-host/hypervisor (or even secure/no-secure should people want > > it) as bindings are defined in an ad-hoc forum (not by an OS community) > > > > Hello François, > > > > Thanks for sharing. > > > > Which organization do you refer to by ad-hoc forum? Ad-hoc does not sound > > like a specification body. Wouldn't this work be done in the UEFI Forum? > > Yes > > > > If ACPI looses the dynamic powers of ASL, what purpose would it serve that > > is not already covered by device-trees? > > Absolutely. And so from a descriptive point of view they are « equal ». The > > existential DT problem is its life cycle , i.e. not provided by firmware > > (secure or not). A new forum should be established to address arm, riscv > > x86 to define DT (EBBR is a good example that cross arch collaboration can > > be done. And Linux community shall stop tinkering all the time with this. > > > > Do the Mercedes aficionados plan to upstream the drivers changes? > > It will/is in efi forum. There will be public publications by other vendors. > > > > Best regards > > > > Heinrich > > > > > > > > DT community leaders and enthusiasts, I believe discussion on the bigger > > picture related to DT relevance in the long run may be needed as I believe > > many embedded solutions will follow Mercedes example. > > IMO the reason ACPI doesn't have to worry about the OS needing a > particular devicetree is that the ACPI tables don't describe > everything.
ACPI tables and AML do describe everything that cannot describe itself, otherwise, how would the OS know about the presence of those undescribed peripherals? The main difference is the level of abstraction: AML carries code logic along with the device description that can en/disable the device and put it into different power states. This is backed by so-called OperationRegions, which are ways to expose [abstracted] SPI, I2C and serial busses to the AML interpreter (as well as MMIO memory) so that the code sequences effectuating things like power state changes can be reduced to pokes of device register, regardless of how those are accessed on the particular system. On x86, many onboard devices are simply described as PCIe devices, even though they are not actually connected to any PCIe fabric. This solves the self-description problem, vastly reducing the number of devices that need to be described via AML. Also, there is a lot more homogeneity in how the system topology is constructed: on embedded systems, it is quite common to, e.g., tie the PHY interrupt line from the PCIe NIC to some GPIO controller that is not a naturally associated with that device at all, and this is something ACPI struggles with, and where DT shines. DT simply operates at a different abstraction level - it describes every detail of the system topology, including every clock generator and power source. This makes it very flexible and very powerful, but also a maintenance burden: e.g., if some OEM issues a v2 of some board where one clock generator IC has been replaced because the original is EOL, it requires a new DT and potentially an OS update if the new part was not supported yet. ACPI is more flexible here, as it can simply ship different ACPI tables that make the v2 board look 100% identical to the v1 as far as the OS is concerned. But the problem re having to worry about the OS needing a particular devicetree has nothing to do with any of this. The problem here is that there is no process or hygiene in the kernel community around backward compatibility. The exact same piece of equipment is described in a different way in every kernel version. And how these descriptions differ from one another is not documented. If DT bindings were versioned, and drivers would remain compatible with the old version as support for a new one is added, many of the kernel vs DT version issues would go away, and only actual bugs/inaccuracies in device trees would require firmware updates or other means to switch over to an updated version. However, there is no ambition whatsoever in the Linux community to address these issues. Developers are actively opposed to putting DTs in firmware, because then they are on the hook to honour the bindings indefinitely. > The new way to handle this seems to be with an OEM- or > device-specific Windows driver. I'm not sure how that would work in > Linux. This is why the Windows-on-ARM ACPI laptops cannot boot in ACPI mode in Linux: ACPI is not suitable for describing these systems, and so on Windows, they basically re-invented board files for ACPI (called PEP). This is mostly due to the complex SoC topology, which pure ACPI cannot describe with sufficient accuracy and so they just ship some board-specific drivers and wire them up via minimal ACPI abstractions. > My Qualcomm laptop (using Linux) currently just reboots if it > gets too hot. > Not sure what you are trying to say here. Is this a dig at ACPI? Or Windows? Or both? _______________________________________________ boot-architecture mailing list -- [email protected] To unsubscribe send an email to [email protected]
