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.
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; which is quite common in hobbyist targeted SBCs. With some devices you may want to boot from other block storage such as USB or SATA if your hardware supports that. So in those cases you have to be cognizant of boot loader firmware locations if you want GPT partition table, as most user guides and sample disk images for these systems assume MBR style partition table with fat32 with the system-specific boot offset locations.
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.
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)
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.
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.
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.
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.
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.
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.
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?
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)
There 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?
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:
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
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; which is quite common in hobbyist targeted SBCs. With some devices you may want to boot from other block storage such as USB or SATA if your hardware supports that. So in those cases you have to be cognizant of boot loader firmware locations if you want GPT partition table, as most user guides and sample disk images for these systems assume MBR style partition table with fat32 with the system-specific boot offset locations.
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.
That is what the Arm SystemReady Compliance Program was supposed to achieve. Unfortunately not many manufacturers are following it yet
https://www.arm.com/architecture/system-architectures/system...
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)
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.
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.
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.
https://docs.u-boot.org/en/latest/develop/uefi/uefi.html
U-Boot does actually have some support for GOP Video¹. It's rather new, so it might be worth revisiting with your specific devices.
¹ https://u-boot.org/blog/seeing-is-believing-video-support-la...
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.
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.
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.
UEFI is one step in many missing steps PCs take in the boot process that ARM SoCs in general don't.
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.
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.
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.
what areas of u-boot do you find much simpler than edk2?
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.
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)
There 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?
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...
1. https://github.com/riscv-non-isa/riscv-uefi/releases
Ugh. Instead of propagating UEFI further, we as an industry should be promoting and improving IEEE 1275 Open Firmware.