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.

This patchset applies on top of the "vsprintf and short-wchar for
EFI_LOADER" patchset, and the first two patches are additional

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.

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

(I'm ignoring secure boot, it is out of scope here.)

For example, if you had both fedora and opensuse installed on the
same disk in different partitions, you would have both:

 + \EFI\fedora\boot.csv
 + \EFI\opensuse\boot.csv

The former would contain the filename of \EFI\fedora\shim.efi and the
latter to \EFI\opensuse\shim.efi (each of which would know to load
\EFI\fedora\grubaa64.efi or \EFI\opensuse\grubaa64.efi).  Based on
this, fallback.efi would setup EFI_LOAD_OPTION's Boot0000 and
Boot0001 (and BootOrder would control the order the load-options
are considered).

With a real UEFI fw there would also be some sort of boot-order menu
(ie. hold down f9 at boot, and get a menu to pick which of the Boot*
load-options to try first).  That is not part of this patchset but
would be a useful next step to allow installing multiple operating
systems on the same disk.

This patchset provides EFI variable support during bootservices,
so viewing or modifying EFI variables after linux ExitBootServices()'s
is not possible.  If the board supports saveenv() this will be called
in efi_exit_boot_services() to persist variables that where set during
the boot process.  Making variables available after EBS is tricky on
hardware that does not have dedicated storage, as after EBS u-boot no
longer controls the devices.  An approach that Alexander Graf
suggested, is that since reboot/halt is controlled via UEFI, is that
on boards that can ensure memory is persisted across reboot, to
store modified EFI variables in a special memory location and turn
halt into reboot uboot -> appropriate setenv() calls -> saveenv() ->
halt in order to persist modified variables.  Which is also not part
of this patchset, and will likely require some board-specific help.

Thanks to Peter Jones for a couple of the patches, and a bunch of help
understanding what the things above the UEFI fw expect (and fixing a
few shim and grub bugs that we found along the way).

Since v0 of the patchset, notable changes:
 * drop reintroduction of efi_handler::open(), it wasn't really needed
   and conflicts with some patches Heinrich is working on
 * splitout vsprintf patches into their own patchset
 * various fixes

Peter Jones (2):
  part: extract MBR signature from partitions
  efi: add some more device path structures

Rob Clark (13):
  fs: add fs_readdir()
  fs/fat: implement readdir
  efi_loader: add device-path utils
  efi_loader: drop redundant efi_device_path_protocol
  efi_loader: flesh out device-path to text
  efi_loader: use proper device-paths for partitions
  efi_loader: use proper device-paths for net
  efi_loader: refactor boot device and loaded_image handling
  efi_loader: add file/filesys support
  efi_loader: support load_image() from a file-path
  efi_loader: make pool allocations cacheline aligned
  efi_loader: efi variable support
  efi_loader: add bootmgr

 cmd/bootefi.c                            | 249 +++++++---------
 cmd/fs.c                                 |  14 +
 disk/part_dos.c                          |  12 +-
 disk/part_efi.c                          |  20 ++
 fs/fat/fat.c                             |  94 ++++--
 fs/fs.c                                  | 101 +++++++
 include/blk.h                            |  15 +
 include/config_distro_bootcmd.h          |   5 +
 include/efi.h                            |  25 ++
 include/efi_api.h                        | 154 +++++++++-
 include/efi_loader.h                     |  56 +++-
 include/fat.h                            |   4 +-
 include/fs.h                             |  25 ++
 include/part.h                           |   3 +-
 include/part_efi.h                       |   4 -
 lib/efi_loader/Makefile                  |   3 +-
 lib/efi_loader/efi_bootmgr.c             | 169 +++++++++++
 lib/efi_loader/efi_boottime.c            | 123 +++++++-
 lib/efi_loader/efi_device_path.c         | 489 +++++++++++++++++++++++++++++++
 lib/efi_loader/efi_device_path_to_text.c | 242 +++++++++++----
 lib/efi_loader/efi_disk.c                |  86 ++++--
 lib/efi_loader/efi_file.c                | 468 +++++++++++++++++++++++++++++
 lib/efi_loader/efi_image_loader.c        |   4 +
 lib/efi_loader/efi_memory.c              |   5 +-
 lib/efi_loader/efi_net.c                 |  24 +-
 lib/efi_loader/efi_runtime.c             |  17 +-
 lib/efi_loader/efi_variable.c            | 342 +++++++++++++++++++++
 27 files changed, 2442 insertions(+), 311 deletions(-)
 create mode 100644 lib/efi_loader/efi_bootmgr.c
 create mode 100644 lib/efi_loader/efi_device_path.c
 create mode 100644 lib/efi_loader/efi_file.c
 create mode 100644 lib/efi_loader/efi_variable.c


U-Boot mailing list

Reply via email to