Bug#1085707: ITP: u-boot-efi-dtb -- copy DTBs to the EFI System Partition from the linux-image-* packages

[Aurelien Jarno]

Package: wnpp
Severity: wishlist
Owner: Aurelien Jarno <***@debian.org>
X-Debbugs-Cc: debian-***@lists.debian.org, debian-***@lists.debian.org

* Package name : u-boot-efi-dtb
Version : 1
Upstream Contact: Aurelien Jarno <***@debian.org>
* URL : https://salsa.debian.org/aurel32/u-boot-efi-dtb
* License : GPL-2+
Programming Lang: shell script
Description : copy DTBs to the EFI System Partition from the linux-image-* packages

This package automatically create and keep up-to-date a dtb/ directory on the
EFI System Partition (ESP) using the device tree blobs (DTBs) from the
installed linux-image packages. When U-Boot is running in UEFI mode, it can
then load the appropriate DTB for the board during the distroboot process.
This ensures that the DTB passed to the kernel is kept up-to-date, even when
using an older U-Boot versions.

---8<---

This is a native package useful for the riscv64 port, but which might also be
useful for some arm boards, therefore the goal is to provide the binary as a
arch:all package.

[Simon Richter]

Hi,

Post by Aurelien Jarno
This is a native package useful for the riscv64 port, but which might also be
useful for some arm boards, therefore the goal is to provide the binary as a
arch:all package.

I remember the absolute insanity when ACPI was new and we basically
assumed any pre-2000 BIOS would have bad tables, and if you wanted ACPI,
you needed to bring your own tables.

I do not wish to repeat this experience, and my feeling is that the way
the boot specifications are written for riscv, with every side pushing
responsibility away from themselves, we are going exactly that way.

Information about mainboard resources needs to be provided by the
bootloader to the OS. Whether that happens as a proper device tree, a
flat one, or as instructions how to build one (as with ACPI) is not
relevant as much as who is responsible for determining how much RAM is
actually present, and where.

I wonder if it would make sense for Debian to throw a bit of weight
around and communicate to vendors that they can not expect us to ship
and update DTBs for their devices in a stable release, and if they want
trixie to be bootable without any vendor specific tricks, they ought to
provide a device tree containing mainboard resources from their
first-stage bootloader so it is already accessible to OpenSBI, and
whatever bootloader is called from that will only amend it with runtime
information like commandline parameters and address assignments of PCIe
devices, not replace it as a whole -- because that is a complete
maintenance and usability nightmare.

Simon

[Jonathan McDowell]

Post by Aurelien Jarno
This is a native package useful for the riscv64 port, but which might also be
useful for some arm boards, therefore the goal is to provide the binary as a
arch:all package.

I remember the absolute insanity when ACPI was new and we basically assumed
any pre-2000 BIOS would have bad tables, and if you wanted ACPI, you needed
to bring your own tables.
I do not wish to repeat this experience, and my feeling is that the way the
boot specifications are written for riscv, with every side pushing
responsibility away from themselves, we are going exactly that way.

It's worth noting this is also a problem for ARM64 laptops, not just
riscv64 boards; my X13s requires a DTB on the EFI partition to boot
successfully. I too would prefer not to undo the progress that has been
made from the every board is special days, but here we are.

J.