On Sat, Dec 26, 2015 at 03:31:03PM +0000, Leif Lindholm wrote:
On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:
This is my Christmas present for my openSUSE friends :).
U-Boot is a great project for embedded devices. However, convincing everyone involved that only for "a few oddball ARM devices" we need to support different configuration formats from grub2 when all other platforms (PPC, System Z, x86) are standardized on a single format is a nightmare.
So we started to explore alternatives. At first, people tried to get grub2 running using the u-boot api interface. However, FWIW that one doesn't support relocations, so you need to know where to link grub2 to at compile time. It also seems to be broken more often than not. And on top of it all, it's a one-off interface, so yet another thing to maintain.
That led to a nifty idea. What if we can just implement the EFI application protocol on top of U-Boot? Then we could compile a single grub2 binary for uEFI based systems and U-Boot based systems and as soon as that one's loaded, everything looks and feels (almost) the same.
This patch set is the result of pursuing this endeavor.
Thanks, this is a very cool thing. I meant to reply sooner, but Christmas got in the way.
- I am successfully able to run grub2 and Linux EFI binaries with this code.
- When enabled, the resulting U-Boot binary only grows by ~10kb, so it's very light weight.
- It works on 32bit ARM and AArch64.
- All storage devices are directly accessible
- No runtime services (all calls return unimplemented)
Yeah, this is a bit of a pain point. The time services, virtual memory services and reset being the key ones.
- No EFI variables
This would obviously (from my point of view) be desirable, but at least initially, we can do most things without persistent variables.
Of course, there are still a few things one could do on top:
- Implement removable media booting (search for /efi/boot/boota{a64,rm}.efi)
Yeah, that would be top of my wishlist.
- Improve disk media detection (don't scan, use what information we have)
- Add EFI variable support using NVRAM
- Add GFX support
GFX support was actually never implemented for U-Boot GRUB, so from this p.o.v. it is not a shortcoming over the existing impementation.
- Make EFI Shell work ;)
- Network device support.I also spotted a couple of minor things while playing around (things like image exit being missing), but these will be easy to flush out.
I'll leave reviewing of the u-boot side of things to people who know the codebase better, and restrict myself to commenting on the UEFIness.
So, my only "big" concern here is, are we as a community able to view and implement the relevant parts of the UEFI spec (without having to agree to a potentially complicated enough license to have to bug a lawyer)? It's been a while since I tried to view a copy so I'm hoping the answer is now yes. Thanks!