U-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¹ supported device.
Some arm devices such as the i.MX6, are strict on the placement of their boot firmware where it would interfere with a normal GPT table. One solution to this is to use a special "--move-main-table" option in gdisk² so that the GPT doesn't clobber U-Boot. While technically GPT is optional as long as U-Boot can read your main partition, I still always setup GPT anyway or Systemd Boot complains.
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.
BadBadJellyBean 8 hours ago [-]
This 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.
robotnikman 7 hours ago [-]
That is what the Arm SystemReady Compliance Program was supposed to achieve. Unfortunately not many manufacturers are following it yet
There is a UEFI standard in some of Arms specs, but it’s only mandatory for the server class IP atm. Some soc vendors are starting to adopt it even in non-server class but it’s slow. My feedback to an Arm devrel a few years ago was exactly this though: you need to provide a consistent standard boot path that also helps OS authors with enough bootstrap that debugging is less of a crapshoot every single time. I hope some progress is made on pushing that down the stack.
When the topic comes up some people express a lot of hatred for uefi (mostly users rather than implementors) but where it’s implementors the ms style APIs and so on are largely the center of it IME, and that’s not really an easy fix when it’s already spec’d. Sometimes there are concerns about size, but slimmed down deployments are common in the socs that ship already - perhaps standardizing on what that slimmed down thing is might help too. May also assuage some of the other concerns of excessive runtime services (which seems rare, but I get the existential concern)
7 hours ago [-]
userbinator 6 hours ago [-]
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.
heavyset_go 5 hours ago [-]
It's this. UEFI doesn't solve the problem of peripheral discovery, for example.
SBSA standard in the server realm seems to have it figured out.
bpye 8 hours ago [-]
For completeness sake - uboot can also boot EFI binaries, though upstream won’t support GOP video on RK3588, and is also device tree only so no Windows, just Linux and BSDs.
The 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.
ajb 7 hours ago [-]
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.
bpye 7 hours ago [-]
Having UEFI in some form means you can just boot your preferred Linux installer and install to disk, much as you would for an x86 device, rather that needing to get a specific disk image and dd it to an SD card.
heavyset_go 5 hours ago [-]
UEFI is one step in many missing steps PCs take in the boot process that ARM SoCs in general don't.
general1465 6 hours ago [-]
Then you can have ARM64 Linux which boots on anything what has UEFI, like today having x86/x64 Linux which boots on everything what has x86 processor inside under expectation that the mother board has BIOS/EFI/UEFI as well.
Just look on Android phones - i.e. Lineage OS, special Android build for every phone. That would not be necessary if booting process would the same.
johnklos 4 hours ago [-]
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.
JdeBP 1 hours ago [-]
OpenBSD, too. I haven't tried FreeBSD on EFI on arm64 yet, but FreeBSD has done EFI on amd64 since version 10.
yusyusyus 5 hours ago [-]
maybe one of the BSP people can give more info, but i believe that it comes with e.g. ACPI and such to avoid device trees.
raggi 6 hours ago [-]
what areas of u-boot do you find much simpler than edk2?
LargoLasskhyfv 6 hours ago [-]
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?
johnklos 4 hours ago [-]
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.
inamberclad 4 hours ago [-]
UEFI is a fairly insane spec, but at least it's a fairly complete spec. Following it is preferable to custom nonsense. (Spoken as someone writing a custom non-UEFI bootloader right now)
snvzz 4 hours ago [-]
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.
For example, right now I have an old armhf i.MX6 Wandboard Quad that runs:
That same layout should be doable on any U-Boot¹ supported device.Some arm devices such as the i.MX6, are strict on the placement of their boot firmware where it would interfere with a normal GPT table. One solution to this is to use a special "--move-main-table" option in gdisk² so that the GPT doesn't clobber U-Boot. While technically GPT is optional as long as U-Boot can read your main partition, I still always setup GPT anyway or Systemd Boot complains.
¹ https://docs.u-boot.org/en/latest/develop/uefi/uefi.html
² https://www.rodsbooks.com/gdisk/sgdisk.html
https://www.arm.com/architecture/system-architectures/system...
When the topic comes up some people express a lot of hatred for uefi (mostly users rather than implementors) but where it’s implementors the ms style APIs and so on are largely the center of it IME, and that’s not really an easy fix when it’s already spec’d. Sometimes there are concerns about size, but slimmed down deployments are common in the socs that ship already - perhaps standardizing on what that slimmed down thing is might help too. May also assuage some of the other concerns of excessive runtime services (which seems rare, but I get the existential concern)
SBSA standard in the server realm seems to have it figured out.
https://docs.u-boot.org/en/latest/develop/uefi/uefi.html
¹ https://u-boot.org/blog/seeing-is-believing-video-support-la...
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.
Just look on Android phones - i.e. Lineage OS, special Android build for every phone. That would not be necessary if booting process would the same.
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.
Or something 3D-printed...
Or did you mean the height of the ports on the backside itself is too large for 1U already?
The metal back panel is standard. It'd be nice to have one that's made to fit 1U cases.
There is also a specification[2] on how UEFI is to be implemented.
0. https://github.com/riscv-non-isa/riscv-server-platform/relea...
1. https://github.com/riscv-non-isa/riscv-uefi/releases