Ubuntu
debian-installer package

Cannot boot installer on platforms requiring Device Tree

Bug #1819443 reported by Lee Jones
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
debian-installer (Ubuntu)
New
Undecided
Unassigned

Bug Description

In the past, when booting Linux on non-(x84_64|i386) machines, it was a requirement to configure and build Linux kernels tailored specifically for a particular device. Now, after many efforts ("one image to rule them all" and the like) to unify and consolidate vendor fragmentation, it is now possible to boot Single Board Computers (SBCs) of similar core architectures with one single binary image.

In order to make this possible Linux is provided with a description of the hardware it is expected to operate on. There are currently two main technologies which provide this functionality; Advanced Configuration and Power Interface (ACPI) and Device Tree (DT). This report only deals with Device Tree (DT).

In an ideal world, firmware installed onto a device would be readily upgradable and thus provide Linux with an up-to-date hardware description that it can work with. However, there are some devices which do not contain either capable or upgradable (or both) firmware, so this information has to be sought from elsewhere.

The kernel packages provided by the Ubuntu build system do contain pre-compiled Device Tree Binaries (DTBs) for currently supported hardware, however these do not make it into the Ubuntu Installers. Instead only a single kernel binary exists which expects to be informed of platform specifics via ACPI tables provided by the platform's firmware. This means that many devices which could easily be supported by the Ubuntu Installer, are not.

There are a couple of ideas which we'd like to put forward to start the conversation off:

 1. Place all supported DTBs into the installer
 2. Allow for a small writable partition on the install media for a user to place a DTB
 3. Enable Grub to be able to pick a DTB from a menu at boot time

At worst case, as long as the DTBs find their way into the installer a user can manually add a 'devicetree' (similar to 'linux' and 'initrd') entry to the Grub menuentry, which would also achieve the aim.

Any help to boot such devices would be gratefully received.

See original description
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

1. Which files are these? can you please give names of .deb and file paths that are in the archive; but missing from the installer environments?

2. We actually do create small writable partitions by default.... do you not see one? and/or is it too small?

3. Sure, or I'd also be ok with a loop of trying them all, and have some mechanism in the initrd to panic the kernel, for the next grub entry to be tried. Or like maybe kexec? See for example how to attempt initrd-less boot, panic, try initrd-full boot on cloud images.

Revision history for this message
Lee Jones (lag) wrote :
Download full text (8.9 KiB)

Thanks for your rapid response.

1. They are pre-compiled DTB files contained in the linux-modules-* packages where 'do_dtbs' is set (currently ARMHF and ARM64).

$ dpkg -l | grep linux-modules
ii linux-modules-4.15.0-29-generic 4.15.0-29.31 arm64 Linux kernel extra modules for version 4.15.0 on ARMv8 SMP
ii linux-modules-4.15.0-34-generic 4.15.0-34.37 arm64 Linux kernel extra modules for version 4.15.0 on ARMv8 SMP
ii linux-modules-4.15.0-43-generic 4.15.0-43.46 arm64 Linux kernel extra modules for version 4.15.0 on ARMv8 SMP
ii linux-modules-extra-4.15.0-29-generic 4.15.0-29.31 arm64 Linux kernel extra modules for version 4.15.0 on ARMv8 SMP
ii linux-modules-extra-4.15.0-34-generic 4.15.0-34.37 arm64 Linux kernel extra modules for version 4.15.0 on ARMv8 SMP
ii linux-modules-extra-4.15.0-43-generic 4.15.0-43.46 arm64 Linux kernel extra modules for version 4.15.0 on ARMv8 SMP

$ apt download linux-modules-4.15.0-43-generic
Get:1 http://gb.ports.ubuntu.com/ubuntu-ports bionic-updates/main arm64 linux-modules-4.15.0-43-generic arm64 4.15.0-43.46 [11.9 MB]
Fetched 11.9 MB in 5s (2,490 kB/s)

$ dpkg-deb -R linux-modules-4.15.0-43-generic_4.15.0-43.46_arm64.deb unpack

$ find . | grep dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/lg/lg1312-ref.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/lg/lg1313-ref.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls2080a-simu.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls1012a-rdb.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls1088a-rdb.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls2080a-rdb.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls1043a-qds.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls1012a-qds.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls2088a-rdb.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls1046a-qds.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls2080a-qds.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls1088a-qds.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls2088a-qds.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls1043a-rdb.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls1046a-rdb.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/freescale/fsl-ls1012a-frdm.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/apm/apm-merlin.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/apm/apm-mustang.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/amd/amd-overdrive-rev-b0.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/amd/amd-overdrive-rev-b1.dtb
./unpack/lib/firmware/4.15.0-43-generic/device-tree/amd/amd-overdrive.dtb
./unpack/lib/firmware/4.15.0-43-gener...

Read more...

description: updated
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

1. The precompiled dtb's -> i can check if we can ship them in the d-i initrd preinstalled, or at least add them for the mini.iso and/or server.iso

2. So for amd64 mini.iso there is a 6M partition free to use for whatever:

$ wget http://archive.ubuntu.com/ubuntu/dists/bionic/main/installer-amd64/current/images/netboot/mini.iso
$ sudo kpartx -av ./mini.iso
$ mount /dev/mapper/loop30p2 /mnt/
$ df -h | grep /mnt
/dev/mapper/loop30p2 6.0M 0 6.0M 0% /mnt

But i don't see anything similar for arm64 unfortunately. The intention is that when one does dd= of this onto e.g. usb-stick, there is a partition to drop e.g. preseed or some weird dkms drivers there.
How much space would we need to drop a dtb? (ie. what's the largest reasonable dtb is?)

3. le sigh
ideally we'd then structure the boot entries somehow sensible in subtrees, or offer an edit to specify the right name, cause there are a lot of them.
Can grub at all guess/detect the right one to use at all? I.e. at least read the top level vendor and/or model names? Cause it would be nice to load the right one automatically, where possible.

Revision history for this message
Lee Jones (lag) wrote :

1. Sounds good. Please let me know your findings.

2. The 142 currently supported DTBs are 4.2M total - the largest single one is 68K.

3. Sub-trees would be fine. They are already formatted that way in the kernel and the *.deb.

   I don't think Grub knows anything about the system without the DT.

Revision history for this message
Lee Jones (lag) wrote :

Has there been any movement on this yet?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.