u-boot.git/cmd/bootefi.c, branch v2017.11

efi_loader: Add mem-mapped for fallback

2017-10-12T15:22:58+00:00

When we don't have a real device/image path, such as 'bootefi hello',
construct a mem-mapped device-path.

This fixes 'bootefi hello' after devicepath refactoring.

Fixes: 95c5553ea2 ("efi_loader: refactor boot device and loaded_image handling")
Signed-off-by: Rob Clark 
Acked-by: Heinrich Schuchardt 
Signed-off-by: Alexander Graf

efi_loader: fix efi_exit

2017-09-21T07:04:25+00:00

efi_exit() already restores gd, so we shouldn't EFI_EXIT() on the
otherside of the longjmp().

Signed-off-by: Rob Clark 
Signed-off-by: Alexander Graf

efi_loader: reenable selftest

2017-09-20T21:34:41+00:00

ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
leads to an error when building with CONFIG_CMD_BOOTEFI_SELFTEST=y
This patch fixes the problem.

Fixes: ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Rob Clark 
Signed-off-by: Alexander Graf

efi_loader: add bootmgr

2017-09-20T09:08:01+00:00

Similar to a "real" UEFI implementation, the bootmgr looks at the
BootOrder and BootXXXX variables to try to find an EFI payload to load
and boot.  This is added as a sub-command of bootefi.

The idea is that the distro bootcmd would first try loading a payload
via the bootmgr, and then if that fails (ie. first boot or corrupted
EFI variables) it would fallback to loading bootaa64.efi.  (Which
would then load fallback.efi which would look for \EFI\*\boot.csv and
populate BootOrder and BootXXXX based on what it found.)

Signed-off-by: Rob Clark 
Signed-off-by: Alexander Graf

efi_loader: efi variable support

2017-09-20T09:00:57+00:00

Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things.  If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload.  (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)

Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky.  One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt.  Whatever the solution, it
likely involves some per-board support.

Mapping between EFI variables and u-boot variables:

  efi_$guid_$varname = {attributes}(type)value

For example:

  efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
     "{ro,boot,run}(blob)0000000000000000"
  efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
     "(blob)00010000"

The attributes are a comma separated list of these possible
attributes:

  + ro   - read-only
  + boot - boot-services access
  + run  - runtime access

NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).

If not specified, the attributes default to "{boot}".

The required type is one of:

  + utf8 - raw utf8 string
  + blob - arbitrary length hex string

Signed-off-by: Rob Clark 
Signed-off-by: Alexander Graf

efi_loader: refactor boot device and loaded_image handling

2017-09-20T08:36:56+00:00

Get rid of the hacky fake boot-device and duplicate device-path
constructing (which needs to match what efi_disk and efi_net do).
Instead convert over to use efi_device_path helpers to construct
device-paths, and use that to look up the actual boot device.

Also, extract out a helper to plug things in properly to the
loaded_image.  In a following patch we'll want to re-use this in
efi_load_image() to handle the case of loading an image from a
file_path.

Signed-off-by: Rob Clark 
Signed-off-by: Alexander Graf

efi_selftest: provide an EFI selftest application

2017-09-18T21:53:57+00:00

A testing framework for the EFI API is provided.
It can be executed with the 'bootefi selftest' command.

It is coded in a way that at a later stage we may turn it
into a standalone EFI application. The current build system
does not allow this yet.

All tests use a driver model and are run in three phases:
setup, execute, teardown.

A test may be setup and executed at boottime,
it may be setup at boottime and executed at runtime,
or it may be setup and executed at runtime.

After executing all tests the system is reset.

Signed-off-by: Heinrich Schuchardt 
Signed-off-by: Alexander Graf

efi_loader: rename __efi_hello_world_*

2017-09-18T21:53:56+00:00

In scripts/Makefile.lib we build section including helloworld.efi.
This allows to load the EFI binary with command 'bootefi hello'.

scripts/Makefile.lib contains explicit references to strings
containing helloworld and hello_world. This makes it impossible
to generalize the coding to accomodate additional built in
EFI binaries.

Let us rename the variables __efi_hello_world_* to
__efi_helloworld_*.

Signed-off-by: Heinrich Schuchardt 
Signed-off-by: Alexander Graf

efi_loader: bootefi hello should use loadaddr

2017-09-18T21:53:56+00:00

Command 'bootefi hello' currently uses CONFIG_SYS_LOAD_ADDR
as loading address.

qemu machines have by default 128 MiB RAM.
CONFIG_SYS_LOAD_ADDR for x86 is 0x20000000 (512 MiB).
This causes 'bootefi hello' to fail.

We should use the environment variable loadaddr if available.
It defaults to 0x1000000 (16 MiB) on qemu_x86.

Signed-off-by: Heinrich Schuchardt 
Signed-off-by: Alexander Graf

efi_loader: use EFI_PAGE_SIZE instead of 4096

2017-08-12T12:06:23+00:00

We should use constant EFI_PAGE_SIZE instead of 4096 where the
coding relies on 4096 being EFI_PAGE_SIZE.

Signed-off-by: Heinrich Schuchardt 
Signed-off-by: Alexander Graf