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

[Leif Lindholm]

On Sat, Dec 26, 2015 at 05:27:48PM +0100, Alexander Graf wrote:
> >> 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.
> 
> I guess reset should be pretty well doable. What are virtual memory
> services? The bits that translate RTS code to run in virtual address
> space somewhere else?

Yup.

> > 
> >>   - 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.
> 
> Doing EFI variables before exiting boot services is easy - we could even
> just map U-Boot variables to EFI variables. That could come in handy for
> cases where you want U-Boot to tell you which board you're on so you can
> refer to different dtb files in your grub.cfg (if you need to override
> the dtb).
> 
> Making them persistent is another difficult question - U-Boot usually
> splits "modify variable" from "store variable pool to nvram".

Indeed.
UEFI might as well, but in more convoluted ways.

> And the hardest part would obviously be to make all of this work while
> Linux is running ;). I'd definitely prefer to defer that bit to later.

Of course.

And again - depending on ambition levels, implementing a version of
efibootmgr that ended up simply tweaking a /boot/uEnv.txt (or similar)
if U-Boot boot environment was detected would be entirely achievable.

> >> 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.
> 
> That should be pretty simple to do - maybe we can even get away without
> any C code for it.

Should be possible.

> > 
> >>   - 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.
> 
> Heh ;). My goal here really is to make U-Boot based systems be en par
> with TianoCore based ones in terms of usability.

Sure. Just setting the nearer goal post of "where can we replace
U-Boot API in GRUB".

> > 
> >>   - Make EFI Shell work ;)
> > 
> >     - Network device support.
> 
> Oh, good point. I forgot about that one.
> 
> > 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.
> 
> Awesome, looking forward to the review! :)
> 
> Thanks a lot for taking the time to look at this patch set.

Sure, this is a very useful thing.

Even at the most cynical possible position (which isn't where I am),
this means additional interface testing using a completely separate
codebase.

/
    Leif