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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
