Hacker News Reader

Comment by iod | Hacker News Reader

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.

¹ https://docs.u-boot.org/en/latest/develop/uefi/uefi.html

² https://www.rodsbooks.com/gdisk/sgdisk.html

View on HN

Does it provide ACPI and the RuntimeServices fully enough to operate as SBSA system?

U-Boot is implementing ACPI, yes, there was something at FOSDEM this year about it for ARM64 machines. QEMU can apparently now boot an arm64 virt machine with only ACPI tables and no device tree. This is all very recent. When I was working on a vague equivalent of systemd-stub last year as a fun exercise in UEFI development, I settled on U-Boot for UEFI and QEMU (but with virtualized device tree). I can't remember the specifics of what's unsupported by RuntimeServices when I was working on it. I'm like 99% certain it's not enough for SBSA compliance, at least.

Honestly, my opinion after all this was that UEFI is pretty convenient and nice, and I'm glad U-Boot has its own implementation, even if it isn't fully grown yet; UEFI for the executable spec with a DTB for bringing up the SOC with nothing else was nicer than a lot of embedded boot flows I've handled.

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

Reply on news.ycombinator.com