Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

通知 1
Star 0
Fork 0
U
U-Boot.Mirror

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 10 2月, 2018 1 次提交
  3. 29 1月, 2018 2 次提交
    • H
      efi_loader: catch misspelled bootefi subcommand · 49db1cb8
      由 Heinrich Schuchardt 提交于 
      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: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      49db1cb8
    • A
      efi_loader: Always use EFIAPI instead of asmlinkage · c6fa5df6
      由 Alexander Graf 提交于 
      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: NAlexander Graf <agraf@suse.de>

---

v1 -> v2:

  - Use efi_status_t in all occurences
      c6fa5df6
  5. 23 1月, 2018 3 次提交
    • H
      efi_driver: EFI block driver · 05ef48a2
      由 Heinrich Schuchardt 提交于 
      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: NHeinrich Schuchardt <xypron.glpk@gmx.de>
[agraf: add comment on calloc len]
Signed-off-by: NAlexander Graf <agraf@suse.de>
      05ef48a2
    • H
      efi_loader: store DT in EFI_RUNTIME_SERVICES_DATA memory · 17ff6f02
      由 Heinrich Schuchardt 提交于 
      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: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      17ff6f02
    • H
      efi_loader: consistently use efi_handle_t for handles · 2074f700
      由 Heinrich Schuchardt 提交于 
      We should consistently use the efi_handle_t typedef when
referring to handles.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      2074f700
  7. 01 12月, 2017 8 次提交
  9. 12 10月, 2017 1 次提交
  11. 21 9月, 2017 2 次提交
  13. 20 9月, 2017 3 次提交
    • R
      efi_loader: add bootmgr · 9975fe96
      由 Rob Clark 提交于 
      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: NRob Clark <robdclark@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      9975fe96
    • R
      efi_loader: efi variable support · ad644e7c
      由 Rob Clark 提交于 
      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: NRob Clark <robdclark@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      ad644e7c
    • R
      efi_loader: refactor boot device and loaded_image handling · 95c5553e
      由 Rob Clark 提交于 
      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: NRob Clark <robdclark@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      95c5553e
  15. 19 9月, 2017 3 次提交
  17. 12 8月, 2017 1 次提交
  19. 26 7月, 2017 1 次提交
    • A
      efi_loader: Fix configuration table override · f4f9993f
      由 Alexander Graf 提交于 
      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: NAlexander Graf <agraf@suse.de>
      f4f9993f
  21. 24 7月, 2017 3 次提交
  23. 19 7月, 2017 6 次提交
  25. 03 7月, 2017 1 次提交
  27. 01 6月, 2017 1 次提交
  29. 28 1月, 2017 1 次提交
  31. 19 1月, 2017 1 次提交
  33. 23 11月, 2016 1 次提交
  35. 17 11月, 2016 1 次提交