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

[Alexander Graf <agraf@suse.de>]

On 04.01.16 23:37, Dennis Gilmore wrote:
> On Monday, January 04, 2016 02:54:40 PM Tom Rini wrote:
>> On Mon, Jan 04, 2016 at 07:41:42PM +0100, Andreas F?rber wrote:
>>> Am 04.01.2016 um 19:03 schrieb Andreas F?rber:
>>>> Am 04.01.2016 um 17:56 schrieb Tom Rini:
>>>>> Please note that with the generic distro framework U-Boot will grok
>>>>> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and
>>>>> things Just Work.  I setup a bunch of SD cards with Debian and Fedora
>>>>> over holiday so I can drop them in whatever board and boot up Linux as
>>>>> a
>>>>> sanity test.
> We do not fully support bootloader spec in u-boot today. but I know that we 
> want to one day 
> 
>>>>> I certainly can see a usecase for kicking off an EFI binary as part of
>>>>> fitting into existing work-flows.  But we do already have a something
>>>>> for getting rid of that particular pain-point and it's working :)
>>>
>>> [snip]
>>>
>>> Executive summary: https://xkcd.com/927/
>>
>> Oh pretty much.  I guess the point I am driving at here is that EFI
>> loading (to kick off GRUB2) needs to fit in with the framework that
>> other distros have already adapted to.  Or heck, maybe you can convince
>> them to switch over to this instead?  Hans or Dennis, what do you think?
> 
> not opposed to it, but it is not something that we have evaluated, I know 
> debian have done a lot of work to ensure that their systems support 
> extlinux.conf also. which is the same syslinux format as used by 
> extlinux/syslinux/isolinux on x86, the user experience is somewhat similiar to 
> that of grub on other arches.  Long term I have planed to wire up menu support 
> so you get a menu to interact with rather than a list of boot options, as well 
> as the ability to edit the commandline arguments. I would not say we have 
> perfect support today for extlinux. so far SuSE is the only one saying no to 
> what has been proposed. It was brought up on both the u-boot and linaro cross 
> distro list back in 2013[1][2] with no one saying it was not a good idea.while 
> there was less feedback than I would have liked it was positive.
> 
> Anyway my main question is how dtb support would work. As that really is the 

Ideally the same way as on existing uEFI based AArch64 machines:
Firmware passes it to grub, grub reformats it and passes it on to Linux.

However, as people keep pointing out, we don't live in an ideal device
tree world - especially when thinking about boards that are running
U-Boot today. Chances are pretty good that a device tree that works for
your kernel from today won't run on tomorrow's kernel - or will lack
features.

So we still need to support the devicetree option in grub2 - and it does
work today. The only convenience missing from this patch set (and I'll
look into it once I have runtime service relocation working on 32bit) is
variable export. That way you'd be able to write

  devicetree (hd0,1)/dtb-4.10.2/$fdtfile

in your grub config and u-boot would magically tell you which dtb file
to load. Then - in theory - you wouldn't need any platform specific
logic in your bootloader configuration generation anymore.

> trickiest part that I can think of.  Something that is gracefully dealt with 
> in the extlinux support, regardless of distro.  Going this approach to me 
> feels like trying to put a Ford engine in a GM car by adding a volkswagon 
> gearbox. can we make grub a u-boot application? that is not using CONFIG_API 
> or does not need to have hard coded memory locations in it?  we looked at 

That's what this patch set is about, yes. It'd be the exact same grub2
binary that runs on all other EFI enabled systems. So if you run on
HIP04D01 or AMD Seattle today, chances are pretty good you have
everything in place already.

> grub2 support years ago as we felt that it would be the way to go as it seemed 
> people were standardising on it. and decided that there were too many issues 
> with the implementation for it to be viable.  so we went the route of 
> proposing the extlinux.conf file option. 

I'm no evangelist - if the extlinux.conf solution works for people, I'm
happy if they stick with it. It just simply doesn't work well for us ;).


Alex