In this week’s Ubuntu Engineering spotlight, we’re diving into the technical side of how our generic ARM64 Desktop ISO works out of the box on all sorts of arm64 desktop hardware including Qualcomm Snapdragon laptops. Plus, we’ll share our upcoming plans for Ubuntu 25.10!
Hardware Discovery
Understanding why a single ARM64 ISO that works everywhere is challenging requires some basic knowledge about the differences between ACPI and Device Trees, and how they abstract hardware to enable device-agnostic OS images.
ACPI
ACPI was originally developed by Intel, Microsoft and Toshiba and is the standard way of dealing with device discovery, configuration and power management in the x86 sphere. Nowadays ACPI is owned by the UEFI forum and is gaining popularity on arm64 where it is part of the Base System Architecture (BSA) and Base Boot Requirements (BBR) standards.
In ACPI the firmware generates ACPI tables and supplies ACPI Machine Language (AML) bytecode which the kernel executes in a built-in interpreter. This approach allows device manufacturers to handle most device-specific code in their firmware, eliminating the need for the OS and kernel to have hardware-specific knowledge.
Device Trees
Device trees (DT/DTB) are an alternative solution that has become the standard hardware description format for arm64 embedded devices but also smartphones, Chromebooks and Apple laptops.
In contrast to ACPI, device trees only describe the layout of the hardware while the logic lives in the kernel drivers. The benefit is that static configuration and logic are split. Firmware provides the static part that is unlikely to ever change, while the logic can be readily updated with regular kernel updates. However, this approach requires the code to first be upstreamed into the Linux kernel which some device manufacturers find challenging.
Snapdragon X on Linux
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.
Since there aren’t any device trees provided by the firmware, they have to be loaded as part of the EFI boot chain.
This creates a new challenge for distributions: To ensure these machines work with a portable image, we have to implement some form of device identification and device tree management before the kernel is loaded. The device trees also aren’t static as they are continuously updated and developed as part of the Linux kernel source code.
Ubuntu 25.04 - The status quo
In Ubuntu 25.04 the device tree loading logic is implemented in a GRUB configuration on the installer ISO. The configuration uses the GRUB smbios command to identify the booted device and adds a devicetree command to load a corresponding device tree if needed. This lookup occurs only during the initial boot. Subsequently, the installer pulls in the flash-kernel package which installs a kernel update hook to locate a matching device tree within the new kernel package and installs it to the /boot directory. Grub has its own hook to run update-grub which finds the new kernel, initrd and device tree and generates a matching boot menu entry.
While this solution has enabled us to create ISOs that function reasonably well across various ARM64 laptops, there are some limitations. Adding support for a new device requires adding device-specific logic to multiple packages. Furthermore, we depend on GRUB features unavailable in secure boot mode, as we load unsigned device trees that are inherently incompatible with secure boot.
Other projects have addressed this issue with their own solutions. dtbloader, used by postmarketOS, functions as an EFI driver and uses a similar device tree lookup strategy. Rather than directly comparing raw SMBIOS values, it utilizes Hardware IDs (HWIDs), which are UUIDs generated from the SMBIOS table. systemd incorporated the same functionality into their systemd-stub to load device trees within the UKI EFI Boot stub.
Unfortunately both approaches are not suitable for the generic Ubuntu arm64 ISO out of the box. EFI drivers are not compatible with shim and grub, making secure boot impossible. UKI’s enforcement of a statically built and bundled initrd would break many Ubuntu packages that expect the initrd to be generated locally.
Ubuntu 25.10 - Introducing stubble
Our solution for Ubuntu 25.10 and later is called stubble. A device tree loading EFI stub, originally derived from the systemd-stub but with a very different focus. stubble does only one thing: find and load a device tree (if needed) before loading the kernel.
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. In fact it works so seamlessly that a lot of Ubuntu Concept users are already running a stubble kernel without knowing it.
The resulting bundled image is compatible with grub, shim and our existing kernel signing pipeline. We can sign the entire binary including stubble, kernel and device trees which would allow us to run on secure boot enabled Snapdragon devices (as long as the UEFI 3rd party CA is enabled).
Since stubble reuses the device tree loading logic from systemd-stub (and by extension dtbloader) it will also allow us to work closer with the reset of the Linux community by sharing code and collaborating on a single cross distribution HWID lookup table.
stubble is available on github and as an Ubuntu package. Alongside this post, we have uploaded the technical specification document for stubble. This document offers a more detailed analysis of why existing solutions aren’t suitable out-of-the-box, potential problems an how we avoid them and further implementation specifics.
We need your help
Switching to a HWID based device tree lookup table means we need some help from the community to ensure we have the required information for all the devices that were working with our solution.
At the moment we are syncing our stubble database from the one in the dtbloader repository. There is an open issue tracking all the missing devices. If you have access to any of the missing devices, we would appreciate it if you could share your HWIDs ideally directly as a Pull Request in the dtbloader repository or as a bug report including the output of sudo fwupdtool hwids in our stubble bug tracker (we will make sure to forward it to dtbloader).