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

[Alexander Graf <agraf@suse.de>]

On 26.12.15 20:34, Leif Lindholm wrote:
> 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.

Can you point me to code that uses the time services?

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

I am not aware of anyone using the U-Boot API for grub these days, so
I'm not sure it's an incredibly useful goal. The main pain point distros
seem to have is to make something that "just works" on all systems out
there. Moving into that direction should be our ultimate goal.


Alex