Commit graph

16 commits

Author SHA1 Message Date
Alexander Graf
6698bb343f efi: Conflict efi_loader with different stub bitness
We have 2 users of the EFI headers: efi_loader and the EFI stub. Efi_loader
always expects that the bitness of the definitions it uses is identical to
the execution.

The EFI stub however allows to run x86_64 U-Boot on 32bit EFI and the other
way around, so it allows for different bitness of EFI definitions and U-Boot
environment.

This patch explicitly requests via Kconfig that efi_loader can only be enabled
if the bitness is identical. Because we can run efi_loader on x86_64 without
EFI stub enabled, it also ensures that this case propagates the correct ABI
constraints.

Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-28 21:37:13 +01:00
Heinrich Schuchardt
9f0770ff9c efi_loader: capitalize EFI_LOCATE_SEARCH_TYPE values
Constants should be capitalized.
So rename the values of enum efi_locate_search_type.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-12-01 13:22:55 +01:00
Rob Clark
ad644e7c18 efi_loader: efi variable support
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 <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-20 11:00:57 +02:00
Rob Clark
2a92080d8c efi_loader: add file/filesys support
fallback.efi (and probably other things) use UEFI's simple-file-system
protocol and file support to search for OS's to boot.

Signed-off-by: Rob Clark <robdclark@gmail.com>
[agraf: whitespace fixes, unsigned fixes]
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-20 10:43:54 +02:00
Rob Clark
0d6ab32e37 part: move efi_guid_t
Prep work for next patch.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-20 10:20:00 +02:00
Heinrich Schuchardt
29f1a3670e efi_loader: fix typo in include/efi.h
Fix typo in teh EFI_BOOT_SERVICES_CODE description.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-18 23:53:56 +02:00
xypron.glpk@gmx.de
3c8ffb6875 efi_loader: define all known status codes
efi.h held only a few EFI status codes.

The patch adds the missing definitions for later usage.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-07-19 14:14:40 +02:00
Simon Glass
5abd9137d5 x86: Tidy up selection of building the EFI stub
At present we use a CONFIG option in efi.h to determine whether we are
building the EFI stub or not. This means that the same header cannot be
used for EFI_LOADER support. The CONFIG option will be enabled for the
whole build, even when not building the stub.

Use a different define instead, set up just for the files that make up the
stub.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2016-11-14 23:24:03 +01:00
Simon Glass
a0b49bc334 efi: Use asmlinkage for EFIAPI
This is required for x86 and is also correct for ARM (since it is empty).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-19 09:01:53 +02:00
Mian Yousaf Kaukab
4c02c11de8 efi_loader: provide efi_mem_desc version
Provide version of struct efi_mem_desc in efi_get_memory_map().

EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines
memory descriptor version to 1. Linux kernel also expects descriptor
version to be 1 and prints following warning during boot if its not:

Unexpected EFI_MEMORY_DESCRIPTOR version 0

Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>
2016-09-07 08:49:07 -04:00
Bin Meng
3e6cc35f4e x86: efi: Fix EFI 64-bit payload build warnings
There are lots of warnings when building EFI 64-bit payload.

include/asm-generic/bitops/__fls.h:17:2:
  warning: left shift count >= width of type
  	if (!(word & (~0ul << 32))) {
			^

In fact, U-Boot itself as EFI payload is running in 32-bit mode.
So BITS_PER_LONG needs to still be 32, but EFI status codes are
64-bit when booting from 64-bit EFI. Introduce EFI_BITS_PER_LONG
to bridge those status codes with U-Boot's BITS_PER_LONG.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2016-08-30 09:26:05 +08:00
Bin Meng
3dc51ab0e1 x86: efi: payload: Make EFI payload build again
Since commit 73c5c39 "Makefile: Drop unnecessary -dtb suffixes",
EFI payload does not build anymore. This fixes the build.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2016-08-30 09:26:05 +08:00
Alexander Graf
2bb9b79d64 include/efi_api.h: Add more detailed API definitions
The EFI API header is great, but missing a good chunk of function prototype,
GUID defines and enum declarations.

This patch extends it to cover more of the EFI API. It's still not 100%
complete, but sufficient enough for our EFI payload interface.

Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
2016-03-15 15:19:23 -04:00
Simon Glass
96a8d409a7 efi: Add 64-bit payload support
Most EFI implementations use 64-bit. Add a way to build U-Boot as a 64-bit
EFI payload. The payload unpacks a (32-bit) U-Boot and starts it. This can
be enabled for x86 boards at present.

Signed-off-by: Simon Glass <sjg@chromium.org>
Improvements to how the payload is built:
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-05 08:44:07 -06:00
Simon Glass
476476e73b efi: Add support for loading U-Boot through an EFI stub
It is useful to be able to load U-Boot onto a board even if is it already
running EFI. This can allow access to the U-Boot command interface, flexible
booting options and easier development.

The easiest way to do this is to build U-Boot as a binary blob and have an
EFI stub copy it into RAM. Add support for this feature, targeting 32-bit
initially.

Also add a way to detect when U-Boot has been loaded via a stub. This goes
in common.h since it needs to be widely available so that we avoid redoing
initialisation that should be skipped.

Signed-off-by: Simon Glass <sjg@chromium.org>
Improvements to how the payload is built:
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-05 08:44:06 -06:00
Simon Glass
867a6ac86d efi: Add start-up library code
When running as an EFI application, U-Boot must request memory from EFI,
and provide access to the boot services U-Boot needs.

Add library code to perform these tasks. This includes efi_main() which is
the entry point from EFI. U-Boot is built as a shared library.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-05 08:42:41 -06:00