On 8 Sep 2025, at 20:43, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
ff ff@shokubai.tech 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.
Constructively yours,
François-Frédéric
PS: static ACPI can be handled by a simple parser, do not execute any ACPI byte code, is findable by EFI tables, code base is even smaller than libfdt. _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.orgmailto:boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.orgmailto:boot-architecture-leave@lists.linaro.org