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.

18
Leave a Reply

avatar
18 Comment threads
0 Thread replies
5 Followers
 
Most reacted comment
Hottest comment thread
7 Comment authors
saiprasadgencapcortex-a72davidltJeroen Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
meagain
Guest

How would you go about compiling and installing this?

Jeroen
Guest
Jeroen

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

meagain
Guest

@cnxsoft
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
Guest
davidlt

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
Guest

@cnxsoft
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
Guest
cortex-a72

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
Guest

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
Guest
davidlt

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 feel more like a normal PC.

cortex-a72
Guest
cortex-a72

@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 on Uefi Secure capabilities.
Maybe not all is that complex, I don’t know, but I like your idea.) And I am writing my own UEFI for armv7/armv8. xD

meagain
Guest

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 such as the GIC meaning no boot. I’ve heard EFIDroid have got both Windows 10 Mobile and Windows RT running on certain specific development boards with identical / very similar processors as the Windows RT tablets, but Windows RT in it’s current form is too limited to be able to run on other platforms. It’s a shame, really, as x86 apps can run on ARM either natively if they’ve been ported or via an emulation layer. But hey, RT runs on a HD2 and should in theory run on other devices. If only MS provided a proper Win32 environment on the IoT Core build, that’d be great.

It’d be wonderful to have “proper” UEFI running on ARM, I guess it just needs time.

cortex-a72
Guest
cortex-a72

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
Guest

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
Guest
gencap

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
Guest

@cnxsoft
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
Guest
saiprasad

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.