Hacker News

points by imoverclocked 2 days ago | 0 comments

Well, looking at the mess that is most arm/arm64 SBCs, I understand why it’s nice to have a standard interface that can run (eg) grub. Can UEFI be much smaller? Also yes.

[–] preisschild 2 days ago

some arm64 sbcs support edk2/uefi btw. I make sure I just use those. Look for "Arm SystemReady" certification, which requires this

[–] yjftsjthsd-h 1 day ago

Any chance you could recommend a board or two?

[–] preisschild 1 day ago

I'm currently using the Radxa Q8B, which already includes EDK2 OOTB and provides the device tree to the linux kernel. But its still a new board and some things are not supported in mainline linux yet.

There are also less-powerful RK3588-based boards like the Radxa Rock5 series which are supported by this edk2 port: https://github.com/edk2-porting/edk2-rk3588#platinum. Thanks to collabora the mainline support is quite advanced: https://gitlab.collabora.com/hardware-enablement/rockchip-35...

If you are searching for more powerful enterprise hardware, AmpereOne SoCs have ARM SR certification. You can just use any modern linux distro uefi generic aarch64 iso and it will boot.

[–] yjftsjthsd-h 2 days ago

I think uboot is kinda doing that?

[–] arcfour 1 day ago

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.

[–] kasabali 1 day ago

BIOS had ACPI, too, so I'm not sure how it contributes to the argument.