On Fri, Dec 25, 2015 at 10:02:44AM +0100, Alexander Graf wrote:
> On 24.12.15 12:15, Matwey V. Kornilov wrote:
> > Why just not to implement standard EFI behaviour when EFI looks for
> > boot-efi partition and proceed?
>
> Well, what is "standard EFI behavior"?
>
> There are 2 standard ways I'm aware of:
>
> 1) NVRAM
>
> The default case for 99.9% of the boots on normal EFI systems is based
> on variables in NVRAM that tell EFI which boot device to boot from.
> Since we don't implement EFI variables today, we can't really make use
> of this feature. And because you want to change the default boot device
> at runtime, we'd have to have runtime services be able to modify them
> after exiting boot services.
>
> 2) Removable Media
>
> There is another way implemented for "Removable Media" - mostly intended
> for USB sticks and the likes. Here EFI searches for a defined file name
> (EFI/boot/boot{arm,a64,x64}.efi) on the ESP partition and boots it.
>
> Part 1 is very difficult to do without major rework of a few U-Boot
> components. If EFI becomes the de-facto standard way of booting with
> U-Boot, I think we'll walk down that road, but it's nothing I want to
> have to deal with in the initial enablement discussion.
>
> Part 2 is easy to do. But then again it's also easy to do it using a
> boot script. Or a compiled in bootcmd. If it's really desired.
Sure, I've seen a lot more complicated boot operations than that
shipped in the default environment of many platforms.
> Which brings me to the next idea. What if we just implement exlinux.conf
> support for EFI binaries? Then all you need to do is have an
> extlinux.conf available on your generic EFI media that tells U-Boot
> where to load the grub binary from.
The problem with this is that you're adding things unrelated to UEFI
into a UEFI boot scenario. Now, depending on what you're looking for,
this may be fine - but it will not leave you with the ability to rely
on being able to "just work" with the UEFI support provided by
UEFI-aware operating systems and their installation media.
Basically, it comes down to preference - is this about:
- Leveraging the benefits of UEFI while staying with the U-Boot
codebase.
or
- Leveraging some of the benefits of UEFI in order to give distros a
more device-independent way of supporting U-Boot platforms.
> That way we wouldn't bend U-Boot completely away from its heritage, make
> use of its flexibility and all distributions that actually care about
> booting from U-Boot would easily be able to just put such a file in an
> rpm an install it always.
You would also need a way to distinguish whether booting with UEFI or
U-Boot efiload.
Sure, compared to stuff like flash-kernel, this is hardly rocket
science, but would be worth standardising early and hard.
> > If ARM board developers will enable EFI support in the future, we can
> > have single one JeOS having all possible dtb in KIWI image.
> > BeagleBone Black has its own u-boot on eMMC, and the user need to push
> > S2 button to force hardware to use our openSUSE u-boot from SD card.
> > Maybe something like that is for other boards. If the single one
> > required u-boot feature is to run EFI grub, then we can even don't
> > touch preinstalled bootloader, that is not possible now, because we
> > need our openSUSE boot scripts.
>
> There are more things we need to solve before we can truly get to a
> universal booting solution. But one step at a time :).
>
> The reason I implemented "bootefi" was really because it's the natural
> fit into how U-Boot handles all other formats today. I don't think this
> is going to be the last patch set around EFI support.
>
>
> Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
