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.
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 · 1h 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)
No comments yet
userbinator · 49m 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.
bpye · 3h 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 · 1h 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 · 1h 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.
general1465 · 1h 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.
raggi · 1h ago
what areas of u-boot do you find much simpler than edk2?
LargoLasskhyfv · 1h 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?
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)
No comments yet
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.
Or something 3D-printed...
Or did you mean the height of the ports on the backside itself is too large for 1U already?