Hacker News
points by arcfour 1 day ago | 0 comments
You need to compile a device tree for every single device you want to support individually, whereas x86 has ACPI to avoid that mess. ACPI is its own mess, yes. And UBoot is great. But it isn't a standalone replacement for a unified firmware interface/"BIOS"/whatever.
[–] cowlevel 1 day ago
It's basically the same solution just in a different format. Device tree specifies device types while ACPI specifies the bytecode to interact with them, but the idea behind both is the same: the computer firmware tells the OS how to interact with it. It's been a slight success in both forms but not nearly as good as you'd hope it to be. The real problem is that nobody's testing all the firmwares and OSes for compliance so lots of devices ship incorrect data in firmware and then the OS has to patch it anyway.

Also uboot is firmware, there's no lower layer it runs on so of course it has to include the device tree. Or in practice, like most vendors, you just put the device tree in the kernel because you know your kernel runs on one specific device model anyway and then you can just edit it when you discover why it's wrong, instead of doing a weird dynamic patching thing.

[–] imoverclocked 1 day ago
Uboot contains a device tree which may or may not be in sync with your kernel device tree. Recent uboot supports efi which then muddies the water more.

When vendors ship a specific kernel, you are unlikely to get security updates in a timely fashion, if ever.

There should be no need for any of this in 2026.

[–] cowlevel 1 day ago
How should it be solved instead?
[–] imoverclocked 1 day ago
Well, for one, the dtbs don't belong with the shipped kernel. If a dtb exists, it should be shipped on the hardware (perhaps as part of firmware.) Right now, there is an intricate dance in some arm setups where:

The installed kernel has 200+ dtbs shipped with it and the boot loader has to be configured by some non-standard userspace glue to detect the correct dtb before rebooting. This glue doesn't exist everywhere and can be ad-hoc per-board or completely non-existent. IMHO, this leads to folks just not updating kernels.

One nice thing (in theory) about a dtb is that there is no code. Of course, there doesn't seem to be an established standard for finding that data so we are back to relying on specialized boot configuration and code anyway.

One place this all becomes glaringly bad is if you take an SD card and move it from one arm64 node to another; There is a good chance it won't boot. It's no wonder there are so many board-specific OS-images floating around instead of having arm64 installers that just work.

Also, a FDT is useless to most OS and remains primarily a Linux concept that has bled into other spheres (like U-Boot) so why would a manufacturer include it?

So ... what should we actually have? A standard on arm that doesn't depend on the triple of which (OS,board,bootloader) you are running. We should be able to just build an arm64 kernel (BSD/Linux/Windows/whatever...) and have a good chance that the thing just works. If that's done via UEFI, then so be it.

IMHO, given (waves hands) the current state of arm64 boards, arm64 support for Linux should look like:

1) Load a board-specific firmware to provide UEFI via EDK2/U-Boot/custom * This is likely on the board-manufacturer to provide and should be pre-loaded.

2) Run a generic arm64 installer.

[–] cowlevel 21 hours ago
On most devices that aren't PCs, there is no separate firmware - the firmware is part of the software. The boot ROM is just loading a sector and jumping to it. You may implement UEFI as your second or third boot stage if you want to, but it's your responsibility.

You wouldn't want the boot ROM to implement UEFI. It would have many unpatchable bugs and different ones on every device revision. Better to put the UEFI where you can patch it. For instance on a Pinephone booting from SD card, the firmware is on the SD card. Moving the SD card to a different device is putting the wrong firmware on that device, that's why it doesn't boot.

And then once you're shipping your own UEFI impl and shipping a kernel that runs inside UEFI, as part of the same SD card image, the next obvious step is to wonder why you can't short circuit those two layers and run the kernel directly on the hardware.

[–] imoverclocked 8 hours ago
Yup. There is no reason it has to be a ROM though. It can easily be a small flash device sitting on spi or something. Firmware sitting on an SD card is annoying for all the reasons already stated.
[–] kasabali 1 day ago
BIOS had ACPI, too, so I'm not sure how it contributes to the argument.