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.
Alexander 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.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
How would you go about compiling and installing this?
@meagain
He said UEFI was enabled by default in mainline U-boot in the video, so I assume you’d just have to retrieve mainline U-boot and build it following the instructions @ http://elinux.org/RPi_U-Boot. Then you should be able to replace the uboot.bin in Raspberry Pi image, with your own uboot.bin.
I’m guessing the next step is to install and configure grub from Linux. I’ve been looking for details instructions while writing this article, but I have not found anything so far.
Would be nice to just use grub instead of all these custom uboot versions and there parameters
@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.
@meagain
You’d be one of the first, or even the first, to test that, and the developer in the video mentioned he did not try to boot Windows.
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.
@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…
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.
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.
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.
@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
…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.
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.
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.
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
@gencap
Were there many systems affected by secure boot in such a way where Linux could not be installed? I’ve never had issues running Linux on Intel PCs pre-loaded with Windows due to secure boot.
@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
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.