[U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151227/a8d0cf45/attachment.sig>