points by cowlevel 1 day ago | 0 comments
How should it be solved instead?
[–] imoverclocked 1 day ago
[–] 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.
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.