1️⃣1️⃣ Here's the 11th post highlighting key new features of the just published v260 release of systemd. #systemd260 #systemd
ARM laptops have recently started moving from the fringes of the Linux world more towards the middle. In the ARM world the nice ACPI-based auto-discovery of devices that PCs have is not really that common, and Devicetree reigns instead. While ACPI is somewhat OS independent, and hence can easily be provided…
…by firmware, Devicetree is different there: it binds hardware to OS concepts, and hence is somewhat specific to both the system *and* the OS. And that makes things a lot harder in some ways, because it must be provided by the OS but is also device specific, and needs to be there in earliest boot, before the kernel initializes.
In systemd v260 there's now not only infrastructure in place to help with this, but we by default ship with a database that automatically selects the right Devicetree…
…for the system Linux is running on.
In v257 we added the general infrastructure to do such matching in systemd-stub (our EFI stub), based on "CHIDs" (which are hashes of certain SMBIOS identifiers). With v260 we now ship a database (contributed by Canonical, containing entries for various Snapdragon devices), that can be built into UKIs for suitable architectures that make them "just work", very similar to behaviour on PCs: the UKI contains both the Devicetree blobs, and this matching…
…database. systemd-stub then calculates the CHIDs of the local hardware, looks it up in this embedded database, picks the right Devicetree, and finally hands control to the Linux kernel, passing the Devicetree to it.
Or in other words: there's a good chance that in some regards these kinds of laptops can "just work" on Linux.
Well that sounds more like a clever hack than a solution. But that's at least something I guess...
@pid_eins
Also this sounds like as if the only real solution to this problem would be to get ARM device vendors to ship proper ACPI tables somehow.
Also doesn't at least e.g. the Surface Pro X SQ1 have proper ACPI tables and thereby proving that it is very well possible for ARM to have proper ACPI?
@agowa338 @pid_eins they are ACPI but very Qualcomm-flavored and incompatible with Linux.
Some couple catches:
- The ACPI tables in firmware are incomplete. Qualcomm has supplemental ACPI table overlays shipped inside of their Windows driver packages.
And drivers have an ACPI table parser inside for _that_.
As far as I remember, that's a hack that they made when they exceeded 32k functions in the DSDT which made Windows mad.
- Qualcomm relies on a PEP driver instead of ACPI power management
Which is exactly what I ment. But there probably isn't anything we can do to make them ship proper ACPI in the firmware.
However that would be the preferable and non hacky solution...
Lennart Poettering
Klaus Frank
Longhorn