Adding stubble to Ubuntu's generic Arm64 Desktop ISOs
Tobias Heider has written an article that explains changes that are coming for Ubuntu's generic Arm64 desktop ISO images in the 25.10 release. The current solution, Heider says, depends on GRUB features that are unavailable in secure boot mode and require adding device-specific logic to multiple packages. The new solution, called stubble, is derived from systemd-stub:
A bundled stubble image contains stubble itself, a Linux kernel, a HWID lookup table to map devices to device trees and multiple device trees. When grub loads this "kernel", stubble executes first, reads the SMBIOS table to generate HWIDs, looks for a match in the embeeded lookup table and loads a matching device tree before passing control to the actual Linux kernel.
The elegance in this approach lies in how it interacts with the rest of the system. Integrating stubble happens entirely at build time in the kernel package. The stubble package is a build dependency for the kernel. After building the kernel itself, we bundle it with stubble and our DTBs and ship the combined binary instead. The resulting stubble + kernel + dtb bundle can be loaded by grub like any other Ubuntu kernel. No further changes in grub or other packages are necessary to make it work.
Posted Aug 24, 2025 4:39 UTC (Sun)
by alison (subscriber, #63752)
[Link] (1 responses)
The other disappointment in serverland was the widespread decision to stick with ACPI for ARM64. Devicetrees are so much easier to debug and modify than ACPI tables. Embedded developers are spoiled.
Posted Aug 24, 2025 6:01 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link]
(I spent a while arguing against ACPI being an expectation for ARM servers like 15 years ago, I think I was wrong)
Posted Aug 26, 2025 10:37 UTC (Tue)
by qwertyface (subscriber, #84167)
[Link] (6 responses)
Does anyone have a link to something I could read about what makes the ACPI implementation incompatible? Does it deviate from the standard in some way?
Posted Aug 26, 2025 13:15 UTC (Tue)
by tobhe (subscriber, #157486)
[Link] (5 responses)
It does deviate quite a bit. They make heavy use of something called PEP (https://learn.microsoft.com/en-us/windows-hardware/driver...)
Quoting from the link above:
In a way this is similar to how device trees work but implemented in ACPI. The tables only contain static device hierarchy information, the logic moves into the Windows driver and can't be used in Linux. There also isn't any PEP support in Linux at the moment so instead of reusing the static ACPI tables we are "translating" them to DTs.
I am not aware of any good written source but Linaro engineers have talked about it previously, for example in https://fosdem.org/2025/schedule/event/fosdem-2025-6224-w... starting at 0:50
Posted Aug 26, 2025 15:07 UTC (Tue)
by pizza (subscriber, #46)
[Link] (3 responses)
WTF was MSFT+QCOM smoking?
This "solution" combines the worst parts of all worlds, with none of the benefits.
...The entire *point* of ACPI is to avoid needing board-specific drivers.
Posted Aug 26, 2025 16:12 UTC (Tue)
by tobhe (subscriber, #157486)
[Link] (2 responses)
I too would prefer proper ACPI but I don't think "no benefits" is entirely true. PEPs like device trees do have one advantage:
Neither Microsoft nor Qualcomm can easily push firmware updates on those devices, that would have to go through the OEMs and have to be signed with their keys. Splitting structure and logic does make some sense in that context. The hierarchy is static and ideally doesn't ever need to be updated while the code can be maintained and updated like any other piece of software (vs hard to update firmware).
Posted Aug 29, 2025 12:16 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
That's the sliver lining of what is otherwise a massive downside: The kernel has to still be specifically aware of the nuances of *that particular system* for it to function properly.
> Neither Microsoft nor Qualcomm can easily push firmware updates on those devices, that would have to go through the OEMs and have to be signed with their keys
How exactly is this any different from how PCs with UEFI have worked for the past decade? (Or over 2 decades if you include pre-UEFI ACPI)
Posted Aug 29, 2025 20:44 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
UEFI/ACPI both have been insufficient for anything complicated or custom. So we got drivers based on WMI (Windows Management Instrumentation) for things like backlight control. They are mostly trivial, though. I'm not sure that writing a custom driver is much worse than having to deal with per-device quirks and opaque firmware updates that might not be tested with Linux.
Posted Aug 26, 2025 17:04 UTC (Tue)
by qwertyface (subscriber, #84167)
[Link]
I wonder if Ubuntu considered U-Boot?
I wonder if Ubuntu considered U-Boot?
Incompatible ACPI
> The current situation on Snapdragon X machines is somewhat peculiar: While the firmware offers ACPI support for Windows, its implementation unfortunately isn’t Linux-compatible. Therefore, upstream Linux decided to use device trees for supporting this platform instead.
Incompatible ACPI
> PEPs provide dynamic, runtime ACPI methods. The static tables (FADT, MADT, DBG2, etc.) must be implemented in the ACPI firmware, as well as the DSDT/SSDT device hierarchy.
Incompatible ACPI
Incompatible ACPI
The logic is much easier to update as part of the kernel.
Incompatible ACPI
Incompatible ACPI
Incompatible ACPI