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

["Andreas Färber" <afaerber@suse.de>]

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.

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.

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.

Regards,
Andreas

[1] https://github.com/openSUSE/perl-bootloader/pull/81

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)