Bug#1112063: ITP: stubble -- UEFI kernel stub with device-tree loading capability
On Tue, Aug 26, 2025 at 12:22 PM Christopher Obbard <obbardc@debian.org> wrote:
>
> Hi Johannes,
>
> On Tue, 26 Aug 2025 at 11:13, Johannes Schauer Marin Rodrigues
> <josch@debian.org> wrote:
> >
> > Hi,
> >
> > Quoting Christopher Obbard (2025-08-25 21:13:23)
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Christopher Obbard <obbardc@debian.org>
> > > X-Debbugs-Cc: debian-devel@lists.debian.org, Christopher Obbard <obbardc@debian.org>, Tobias Heider <tobias.heider@canonical.com>
> > >
> > > Package name : stubble
> > > Version : v3
> > > Upstream Contact: Tobias Heider <tobias.heider@canonical.com>
> > > 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
Reply to: