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

[Peter Robinson]

On Mon, Jan 4, 2016 at 6:03 PM, Andreas Färber <afaerber at suse.de> wrote:
> 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.
>>
>> 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 :)
>
> No, as I explained before, you are not addressing that particular
> pain-point: extlinux is still something new to implement for us as
> distro, you provide no tools to help us, while on x86, ppc, s390 and
> some aarch64 we have converged on grub2 as a standard, and just recently
> the YaST devs decided to only support grub2 going forward.
>
> For extlinux (which BTW to my eye looked slightly different from the
> freedesktop.org spec that you guys keep referencing?!), distro-specific
> code needs to be written [1] so that on kernel installation the
> /boot/extlinux/extlinux.conf file is regenerated - for grub2 such tools
> simply exist as part of GRUB and this proposed EFI interface for U-Boot
> will avoid having to implement any new, e.g., perl-Bootloader code.

Yes, that is true, but it only has to be done once.

> So the open conflict is that you tell us that extlinux.conf is your
> "distro" mechanism that we should be using, and our distro people are
> telling us that grub2 is their preferred solution after having
> accumulated bootloader code for some two decades and just got rid of it.
>
> Standards are not created through publishing some spec, they are created
> through adoption, and today I don't see anyone at SUSE moving an inch
> towards adopting extlinux.conf as a generic boot mechanism for all
> architectures. That leaves our ARM community at a loss, booting a single
> kernel through a symlink.

It's certainly not ideal but in Fedora (and I believe in Debian too)
we use the distro support in u-boot to boot dozens of devices with
multiple kernels and roll backs.

> No one has suggested to dump extlinux.conf or boot.scr, they can all
> simply co-exist, with the difference that, from the looks of it, Alex'
> EFI code could get enabled by default to allow users to choose using it,
> unlike the disabled CONFIG_API code that I reported got broken by DM
> migration and for many other boards was lacking defines and is in need
> of a board-specific rather than generic second bootloader on the distro
> side.
>
> This patchset is a cute middle ground where for U-Boot it's mostly just
> an additional command, our distro people will be content, and our ARM
> users will be happy too, not having to handcraft extlinux.conf files and
> benefiting from the vibrant U-Boot community as opposed to the much more
> fragmented Tianocore forks out there. Thus I'm hoping we can sort out
> some of the technical issues Leif pointed out and stop circling back to
> this unhelpful oh-but-extlinux.conf-is-the-mechanism point.

Yes, I think it's definitely good value, especially for aarch64
devices where uEFI is currently a much wider tested option due to the
current available devices.