On Mon, Jan 4, 2016 at 6:03 PM, Andreas Färber <afaer...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
