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

[Alexander Graf]

On 26.12.15 16:31, 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.

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?

> 
>>   - 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".

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, 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.

> 
>>   - 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.

> 
>>   - 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.


Alex