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