Hi, On Mon, 8 Sept 2025 at 15:41, ff <f...@shokubai.tech> wrote: > > > > On 8 Sep 2025, at 20:43, Heinrich Schuchardt > <heinrich.schucha...@canonical.com> wrote: > > > > > ff <f...@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.
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. 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. My Qualcomm laptop (using Linux) currently just reboots if it gets too hot. We can deal with the devicetree being in two places, e.g. see this blog post[1] and standard boot. Regards, Simon [1] https://u-boot.org/blog/supercharging-fits-u-boots-new-two-stage-boot-capability/ [2] https://docs.u-boot.org/en/latest/develop/bootstd/overview.html _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
