On Tue, Aug 26, 2025 at 12:22 PM Christopher Obbard <[email protected]> wrote: > > Hi Johannes, > > On Tue, 26 Aug 2025 at 11:13, Johannes Schauer Marin Rodrigues > <[email protected]> wrote: > > > > Hi, > > > > Quoting Christopher Obbard (2025-08-25 21:13:23) > > > Package: wnpp > > > Severity: wishlist > > > Owner: Christopher Obbard <[email protected]> > > > X-Debbugs-Cc: [email protected], Christopher Obbard > > > <[email protected]>, Tobias Heider <[email protected]> > > > > > > Package name : stubble > > > Version : v3 > > > Upstream Contact: Tobias Heider <[email protected]> > > > URL : https://github.com/canonical/stubble > > > License : LGPL2.1 > > > Programming Lang: C > > > Description : UEFI kernel stub with device-tree loading capability > > > > > > Small Linux kernel EFI boot stub bundling device trees, a CHID database > > > and the kernel. The stub finds a matching device tree based on CHIDs > > > generated from SMBIOS and loads it before executing the embedded > > > kernel. > > > > > > Booting generic Distro images on ARM64 laptops is quite hard due to > > > (currently) no way to tell what hardware the image is running on, or to > > > load the correct device tree from the kernel. > > > > > > Stubble aims to mitigate against this by loading the correct device tree > > > for the laptop at runtime. > > > > > > This package will be useful to build ARM64 Debian images which > > > "just-work" on ARM laptops, specifically Qualcomm X-Elite laptops. > > > > I'm very interested in this as I maintain the Debian integration for the MNT > > Reform and MNT Pocket Reform open hardware laptop. They usually boot via > > u-boot > > and then either /boot/boot.scr or /boot/extlinux/extlinux.conf which are > > populated by flash-kernel and u-boot-menu with the correct device tree for > > the > > platform, respectively. We can create images that work on all platforms > > supported by MNT by using u-boots $fdtfile option which allows the > > platform-specific u-boot binary to select the right device tree from an > > otherwise device-agnostic system image. > > > > I already have a POC for EFI booting with EDK2 but one big downside is, that > > using the facilities provided by systemd-ukify, systemd-boot and > > systemd-boot-efi creates a binary which has a device-specific dtb baked into > > the binary making it device specific. > > > > If stubble would allow us to create efi stubs which are identical > > independent > > of the platform because they select the dtb "at runtime" then I am extremely > > interested in using stubble for the MNT Reform. > > > > Can you confirm that stubble might be providing the functionality we are > > looking for? > > Yes, it looks like it will also work perfectly for this use case :-). > The idea is to generate a UKI image in the standard systemd-boot way, > but with the generic "stubble" stub instead of systemd-boot's stub, > kernel, initrd, as well as a list of DTBs to choose from. > This UKI image could then be signed with MOK (or signed upstream... > but that's a little further down the road I guess). > When stubble loads, it detects which DTB to load (currently by > matching CHIDs in stubble to what is running on the hardware).
Agreed, a few more considerations: You need some way to identify the device. Currently that can either be the SMBIOS table (from which the HWIDs are generated) or a compatible property from a dtb passed by firmware. Stubble will by default override the firmware provided dtb with an embedded one if they share the same compatible. This behavior can be changed with a kernel command line option for users who want to load their own dtb in u-boot/grub. systemd UKI actually supports both methods too. In fact we borrowed the implementation from there. One big difference is that stubble does not require a pre-built initrd that is included in the bundle so it won't break any packages providing initramfs-tools scripts or hooks. > > Thanks! > > Chris
