Skip to content
Snippets Groups Projects
Select Git revision
3 results
Search by author
  • Any Author
0 authors
  1. Jun 14, 2018
    • Alexander Graf's avatar
      efi_loader: Allocate memory handle for mem dp · 58bc69d2
      Alexander Graf authored 
      
When we boot using memdp (bootefi on an address without previous
load that populates the device path) then the memory device path
we pass in is not backed by any handle.

That can result in weird effects. For example grub gets very grumpy
about this inside the efi_net module and just loops endlessly.

So let's expose a simple handle that the memory device path is backed
on. That way any code that looks for the device the dp is on, finds
one.

Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      58bc69d2
  3. Jun 03, 2018
  5. May 11, 2018
  7. Apr 13, 2018
  9. Apr 06, 2018
    • Alexander Graf's avatar
      efi_loader: Respect DT reserved regions · 806d2fa8
      Alexander Graf authored 
      
With legacy boot (booti, bootz), people can declare memory regions as
reserved using device tree memory reservations. This feature is some
times used to indicate memory regions that should not be touched.

Since in a UEFI world, the DT memory reservations do not get honored,
let's copy them into the UEFI memory map so everyone has a coherent
view of the world and we give people the chance to add reservations
on demand.

Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      806d2fa8
  11. Apr 04, 2018
  13. Mar 05, 2018
  15. Feb 27, 2018
  17. Feb 09, 2018
  19. Jan 28, 2018
    • Heinrich Schuchardt's avatar
      efi_loader: catch misspelled bootefi subcommand · 49db1cb8
      Heinrich Schuchardt authored 
      
If 'bootefi hello' or 'bootefi selftest' can be executed depends on the
configuration.

If an invalid non-numeric 1st argument is passed to bootefi, e.g.
'bootefi hola', this string is converted to 0 and U-Boot jumps to
this typically invalid address.

With the patch the online help is shown instead.

Signed-off-by: default avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      49db1cb8
    • Alexander Graf's avatar
      efi_loader: Always use EFIAPI instead of asmlinkage · c6fa5df6
      Alexander Graf authored 
      
EFI calls are usually defined as asmlinkage. That means we pass all parameters
to functions via the stack x86_32.

On x86_64 however, we need to also stick to the MS ABI calling conventions,
which the EFIAPI define conveniently handles for us. Most EFI functions were
also marked with EFIAPI, except for the entry call.

So this patch adjusts all entry calls to use EFIAPI instead of the manual
asmlinkage attribute.

While at it, we also change the prototype of the entry point to return
efi_status_t instead of ulong, as this is the correct prototype definition.

Signed-off-by: default avatarAlexander Graf <agraf@suse.de>

---

v1 -> v2:

  - Use efi_status_t in all occurences
      c6fa5df6
  21. Jan 22, 2018
    • Heinrich Schuchardt's avatar
      efi_driver: EFI block driver · 05ef48a2
      Heinrich Schuchardt authored 
      
This patch provides
* a uclass for EFI drivers
* a EFI driver for block devices

For each EFI driver the uclass
* creates a handle
* adds the driver binding protocol

The uclass provides the bind, start, and stop entry points for the driver
binding protocol.

In bind() and stop() it checks if the controller implements the protocol
supported by the EFI driver. In the start() function it calls the bind()
function of the EFI driver. In the stop() function it destroys the child
controllers.

The EFI block driver binds to controllers implementing the block io
protocol.

When the bind function of the EFI block driver is called it creates a
new U-Boot block device. It installs child handles for all partitions and
installs the simple file protocol on these.

The read and write functions of the EFI block driver delegate calls to the
controller that it is bound to.

A usage example is as following:

U-Boot loads the iPXE snp.efi executable. iPXE connects an iSCSI drive and
exposes a handle with the block IO protocol. It calls ConnectController.

Now the EFI block driver installs the partitions with the simple file
protocol.

iPXE uses the simple file protocol to load Grub or the Linux Kernel.

Signed-off-by: default avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
[agraf: add comment on calloc len]
Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      05ef48a2
    • Heinrich Schuchardt's avatar
      efi_loader: store DT in EFI_RUNTIME_SERVICES_DATA memory · 17ff6f02
      Heinrich Schuchardt authored 
      
The device tree is needed at runtime. So we have to store it in
EFI_RUNTIME_SERVICES_DATA memory.

The UEFI spec recommends to store all configuration tables in
EFI_RUNTIME_SERVICES_DATA memory.

Signed-off-by: default avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      17ff6f02
    • Heinrich Schuchardt's avatar
      efi_loader: consistently use efi_handle_t for handles · 2074f700
      Heinrich Schuchardt authored 
      
We should consistently use the efi_handle_t typedef when
referring to handles.

Signed-off-by: default avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      2074f700
  23. Dec 01, 2017
  25. Oct 12, 2017
  27. Sep 21, 2017
  29. Sep 20, 2017
    • Heinrich Schuchardt's avatar
      efi_loader: reenable selftest · 7aca68ca
      Heinrich Schuchardt authored 
      
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: default avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      7aca68ca
    • Rob Clark's avatar
      efi_loader: add bootmgr · 9975fe96
      Rob Clark authored 
      
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: default avatarRob Clark <robdclark@gmail.com>
Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      9975fe96
    • Rob Clark's avatar
      efi_loader: efi variable support · ad644e7c
      Rob Clark authored 
      
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: default avatarRob Clark <robdclark@gmail.com>
Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      ad644e7c
    • Rob Clark's avatar
      efi_loader: refactor boot device and loaded_image handling · 95c5553e
      Rob Clark authored 
      
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: default avatarRob Clark <robdclark@gmail.com>
Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      95c5553e
  31. Sep 18, 2017
  33. Aug 12, 2017
  35. Jul 26, 2017
    • Alexander Graf's avatar
      efi_loader: Fix configuration table override · f4f9993f
      Alexander Graf authored 
      
Before commit 7cbc1241 ("efi_loader: initalize EFI object list
only once") we recreated the world on every bootefi invocation.

That included the object tree as well as the configuration tables.

Now however we don't recreate them, which means we must not explicitly
override the configuration tables, as otherwise we may lose our SMBIOS
table from the configuration table list on second bootefi invocation.

This patch makes bootefi call our normal configuration table modification
APIs to add/remove the FDT instead of recreating all tables from scratch.
That way the SMBIOS table gets preserved across multiple invocations.

Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      f4f9993f
  37. Jul 24, 2017