Note on RISC-V, the RISC-V Server Platform Specification[0] requires UEFI always.
There is also a specification[2] on how UEFI is to be implemented.
0. https://github.com/riscv-non-isa/riscv-server-platform/relea...
Installing UEFI Firmware on ARM SBCs
21–30 of 53 posts
Re: Installing UEFI Firmware on ARM SBCs
#22The Rock 5 ITX+ is a nice board. I wish a 1U back panel were available for it. UEFI does make things a lot easier. It's a shame that this isn't more common for Arm boards, but it's good to see things heading in the right direction.
That backside is looking rather full. Nothing which a few blocks of styrofoam from packaging residue, maybe some cardboard or other plastics, and adhesive metal tape, and/or some super/hot-glue couldn't easily fill. Or something 3D-printed... Or did you mean the height of the ports on the backside itself is too large for 1U already?
The ports would easily fit in a 1U case, as would everything else, including the fan and heat sink.
The metal back panel is standard. It'd be nice to have one that's made to fit 1U cases.
Re: Installing UEFI Firmware on ARM SBCs
#23The Rock 5 ITX+ is a nice board. I wish a 1U back panel were available for it. UEFI does make things a lot easier. It's a shame that this isn't more common for Arm boards, but it's good to see things heading in the right direction.
Serious question: what things does it make easier? Other than booting windows. I don't know anything about it except that it seems much more complicated than u-boot.
No idea about Windows. No interest, either.
UEFI makes it so you can boot your Unix OS, like NetBSD, without needing to have specific bootblocks that are tailored to the given machine. You can move drives between Arm machines, too. Much simpler.
Re: Installing UEFI Firmware on ARM SBCs
#24Earlier quoted context omitted.
Serious question: what things does it make easier? Other than booting windows. I don't know anything about it except that it seems much more complicated than u-boot.
No idea about Windows. No interest, either. UEFI makes it so you can boot your Unix OS, like NetBSD, without needing to have specific bootblocks that are tailored to the given machine. You can move drives between Arm machines, too. Much simpler.
OpenBSD, too. I haven't tried FreeBSD on EFI on arm64 yet, but FreeBSD has done EFI on amd64 since version 10.
Re: Installing UEFI Firmware on ARM SBCs
#25Ugh. Instead of propagating UEFI further, we as an industry should be promoting and improving IEEE 1275
Open Firmware.
Re: Installing UEFI Firmware on ARM SBCs
#26There are two fundamental issues in the ARM ecosystem for general-purpose computing: the lack of a standard boot environment and the lack of a reliable device auto-discovery mechanism. Device trees still require a lot of manual intervention. I haven't yet come across an ARM board that can boot a vanilla Debian AArch64 image without extra work. This makes me skeptical about the prospects of ARM in the desktop and laptop space. Is it really worth giving up the messy but standards-based x86 platform in exchange for bespoke ARM solutions?
Re: Installing UEFI Firmware on ARM SBCs
#27U-Boot does basic enough UEFI emulation for most use cases. I find that I don't need native UEFI firmware and I can just build U-Boot with UEFI support for most ARM devices. For example, right now I have an old armhf i.MX6 Wandboard Quad that runs: U-Boot -> UEFI (with Secure Boot if desired) -> Systemd Boot (or Linux EFI Boot Stub) -> Debian (or other distro) That same layout should be doable on any U-Boot¹ supporte…
With eMMC can’t you just stick u-boot in a eMMC boot partition? Then the entire eMMC user area can be used without risk of clobbering u-boot.
You of course can, assuming that your hardware configuration supports eMMC with dedicated hardware boot partition(s). Some devices, like the one I used in my example, in its default configuration the hardware is actually booted from a MicroSD card as a regular mmc block device; which is quite common in hobbyist targeted SBCs. In those cases you have to be cognizant of boot loader firmware locations if you want a GPT partition table, as most user guides and sample disk images for these systems assume MBR style partition table reserving only the first block. Followed by system-specific boot blob(s) at the required offset location and then a fat32 partition somewhere thereafter with the OS. If the boot firmware blob starts before the 34th¹ block with 512-byte sectors blocks, then for setting up GPT, you move the main GPT table to after the firmware; otherwise you can just allocate the first partition space as reserved protected area in GPT for the firmware so that it doesn't get written to as a reference for future repartioning.
¹ https://en.wikipedia.org/wiki/GUID_Partition_Table#Features
Re: Installing UEFI Firmware on ARM SBCs
#28Ugh. Instead of propagating UEFI further, we as an industry should be promoting and improving IEEE 1275 Open Firmware.
Why would we base modern computer firmware around a 1994 standard, on which work had mostly stopped by 1998?
Re: Installing UEFI Firmware on ARM SBCs
#29This here is the important next step for ARM SBCs. A working UEFI. Maybe they can get together and standardize something they can work on together. But this whole SD card flashing nonsense needs to stop.
ARM SoCs have always been very proprietary and fragmented, and until/if something like the x86/PC comes along I don't think just UEFI is enough. The PC flourished because of many de-facto standards, and not just the BIOS. Unfortunately the companies these days seem to love their proprietariness, so I don't think something like that will happen again.
PC flourished, because IBM lost control, what is happening with ARM is basically what every other 8 and 16 bit home computers used to be.
Re: Installing UEFI Firmware on ARM SBCs
#30i understand why OP did it. But wouldn't it be nice if we took it all the way and just let the OS figure this out? [1]
This is a radical departure from the abstraction-on-abstraction that is implicated by BIOS/UEFI but it feels like it would make the whole architecture not feel like a fossil once it's out of the vendor's hands.
This would mean that every OS would need to make an implementation and feels like wasted effort, however, looking at all the BIOS bugs that i encountered which were OS specific, I have to say I'd rather see OS specific implementations than having to convince your vendor that you hit a bug which happens to be on a OS other than Windows or an ancient redhat patched Linux kernel.
[1]: https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...