On 14.09.17 00:05, Rob Clark wrote:
This patchset fleshes out EFI_LOADER enough to support booting an
upstream \EFI\BOOT\bootaa64.efi (which then loads fallback.efi and
then eventually the per-distro shim.efi which loads the per-distro
grubaa64.efi) without resorting to hacks to hard-code u-boot to load
a particular distro's grub, or other hacks like setting up the
distro installation as live-media.

Background: with a normal UEFI implementation, the boot process is:

a) firmware (u-boot) looks at BootOrder and the BootXXXX variables
    to try to determine what to boot.
b) the firmware will look at the BootXXXX variables (which contain
    an EFI_LOAD_OPTION "struct" in order specified by BootOrder, and
    will boot the first bootable option.
c) The EFI_LOAD_OPTION specifies a device-path which identifies the
    device and file path of the .efi payload to exectute.

This is implemented with the 'bootefi bootmgr' command.

If there are no bootable options the firmware falls back to loading
\EFI\BOOT\bootaa64.efi (exact name varies depending on arch), which
for distro's using fallback/shim (which should include most modern
linux distros) then loads fallback.efi which uses the
EFI_SIMPLE_FILE_SYSTEM_PROTCOL and EFI_FILE_PROTOCOL to search for
any \EFI\*\boot.csv, and will then set BootOrder and BootXXXX EFI
variables accordingly so that on next boot fallback.efi is not
necessary.

The last 5 patches are a bit unrelated, just pulling forward some of
the patches I have from the next patchset, to get Shell.efi and SCT
working.

I've pulled the patches into efi-next, but want to run them through Travis first and then do some smoke tests myself before sending them as pull request.

Please follow up with fixes to the "unsigned" type warnings. Just use "unsigned int" everywhere.


Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to