U-Boot Now Supports UEFI on 32-bit and 64-bit ARM Platforms

Intel/AMD x86 based computers now boot via a standard UEFI binary, which can load grub2, allows you to update the command line as needed, or select different version of the Linux kernel. On ARM everything is a little more complicated and messy, as bootloaders such as U-boot need to support different configurations formats.

Raspberry_Pi_UEFI_GRUB2_U-BootAlexander Graf has been working on implementing UEFI support in U-boot, and it’s now supported by U-boot mainline and enabled by default for 32-bit and 64-bit ARM platforms, but not x86-64 (yet). That means you should now be able to boot any ARM boards supported by mainline U-boot through UEFI. Alexander gave a presentation about his work at an openSUSE event in June, and demonstrated u-boot with UEFI, and GRUB2 support with an openSUSE image running on a Raspberry Pi board.

Thanks to David for the tip.

Share this:

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard
Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
18 Comments
oldest
newest
meagain
meagain
8 years ago

How would you go about compiling and installing this?

Jeroen
Jeroen
8 years ago

Would be nice to just use grub instead of all these custom uboot versions and there parameters

meagain
meagain
8 years ago


Thanks. I’m relatively new to this kinda thing but I’ve got both a pcDuino (Allwinner A10) and Pi 1 / Zero so it’d be cool to try get this working. I’ve been playing around with EFIDroid also but this looks more convenient for SBCs to play with.

Ultimate goal is to get the WinRT loading screen display on some non-MS ARMv7 device so I guess EFI is a good starting point.

davidlt
davidlt
8 years ago

IIUC from #fedora-arm chats, Fedora will use uEFI (u-boot)/grub2 on aarch64 SBCs. This would apply for the boards like Pine64, ODROID-C2, etc which don’t have Tianocore based uEFI firmware.

meagain
meagain
8 years ago


It *should* boot up. Windows RT will boot to the loading screen on any platform (even the hacked IoT bootloader on the Pi) however will crash on almost all due to lack of drivers for the GIC iirc. Allwinner A10 (pcDuino( *should* be supported OOTB however I doubt this. I might as well try…

cortex-a72
cortex-a72
8 years ago

As always with uboot the whole thing is an entire mess. They didn’t implement UEFI standard in its entirety, instead they did some dirty hacks to be able to run some UEFI payloads (like grub2). It’s everything but UEFI implementation. There is no core services implemented, just stubs. As with any dirty hacks it will be a constant PITA for those wishing to use it, so those are better off to not rely on this untill they really implement UEFI instead of just managing to run grub2. False start detected.

meagain
meagain
8 years ago

I’m doubtful this will work and lack the tools and experience to compile and install this. Theoretically you could boot up /boot/bootarm.efi from a Surface RT recovery image stored on the SD / USB but if the UEFI implementation is as hacky as cortex-a72 says then I doubt it’ll load to be honest.

davidlt
davidlt
8 years ago

You shouldn’t expect everything working on day 1. Even things with AArch64 took years to mature. I think, the main goal was to implement enough of uEFI interfaces to load grub. As said in video not everything described in uEFI specification (interfaces/services) are available on u-boot, thus those would take longer. Looking at recent development looks like they are now also generating and exposing SMBIOS tables (or soon will do it). It’s also part of SBBR requirement. Quote: “I have verified that I get a correct serial number printed in dmidecode on the RPi3.” That’s very cool. It starts to… Read more »

cortex-a72
cortex-a72
8 years ago

@meagain you have a noble but unfeasible goal. 🙂 this is what MS should do – make their arm NT version accessible the same way as x86. If I understand properly MS efi payloads aren’t that easy, to being able run by this mediocre uefi hacking from uboot. for example, MS OSLoader does implement its own Boot manager (which is unnecessary of course, becuase normal UEFI provides Boot Manager (not uboot hacks)). It sshould rely heavily on UEFI exposed services and being highly integrated with the FW. Not to mention Secure Boot things. I believe MS efi applications heavily rely… Read more »

meagain
meagain
8 years ago

cortex-a72 : And I am writing my own UEFI for armv7/armv8. xD …are you the developer of EFIDroid? Or is this something different? I honestly doubt that Microsoft will ever open up the RT / WoA bootloader. It’s an unpopular platform to the masses and the Wintel relationship seems to be stronger than ever. Of course, I’d love to see that happen. I’m pretty sure this didn’t use an implementation of UEFI and rather some proprietary bootloader. Even if we could get Windows booting unless it’s a Qualcomm or possibly Allwinner chip there will be no drivers for vital parts… Read more »

cortex-a72
cortex-a72
8 years ago

No, I am not an EFIDroid developer.
Yes, it won’t boot becuase of lack of support of so many core components. That’s why it’s not feasible without MS change of policy regarding arm platform. I don’t know whether the current Windows RT uses Uefi or proprietary fw, but if arm NT would be released as PC-like platform, then using Uefi+Acpi makes more sense.
Proper Uefi firmware definitely would be the ultimate way of booting on arm, but time is needed.

meagain
meagain
8 years ago

Yup. iirc the RT platform is very PC-based and does use ACPI. I’m pretty sure MS won’t start working on Windows for ARM now for a while, apart from IoT uses where Win32 apps, etc, are disabled.

gencap
gencap
8 years ago

A great day for freedom (https://www.youtube.com/watch?v=SHuI_FWCoPU):

Microsoft leaks backdoor key, firmware flung wide open

http://arstechnica.com/security/2016/08/microsoft-secure-boot-firmware-snafu-leaks-golden-key/

https://rol.im/securegoldenkeyboot/

It’s time to rescue all those paperweights laying around and give them a new life 😉

gc

meagain
meagain
8 years ago


It applies to RT (ARM) devices only according to the arstechnica article. That opens them up to other OSes now RT is basically abandoned

saiprasad
saiprasad
6 years ago

Hi Alexander,

I am newbie to u-boot and at my work i need to develop some routines(initiate DHCP and process the offer packet and communicate with some HSM server using HTTPS) in u-boot UEFI on ARM while at the boot stage itself. so from your explanation, i understand i might need to do coding in boot time services. So is HTTPS support there in U-boot or we need to bring that on our own.

Also can you please let me know any pointers how and where i need to start. I am completely new to U-boot area.

Khadas VIM4 SBC