Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

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

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

切换分支/标签
  1. 25 7月, 2018 3 次提交
  3. 02 7月, 2018 1 次提交
  5. 14 6月, 2018 1 次提交
    • A
      efi_loader: Allocate memory handle for mem dp · 58bc69d2
      由 Alexander Graf 提交于 
      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: NAlexander Graf <agraf@suse.de>
      58bc69d2
  7. 03 6月, 2018 3 次提交
  9. 11 5月, 2018 1 次提交
  11. 14 4月, 2018 1 次提交
  13. 06 4月, 2018 1 次提交
    • A
      efi_loader: Respect DT reserved regions · 806d2fa8
      由 Alexander Graf 提交于 
      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: NAlexander Graf <agraf@suse.de>
      806d2fa8
  15. 04 4月, 2018 5 次提交
  17. 05 3月, 2018 1 次提交
  19. 28 2月, 2018 1 次提交
  21. 10 2月, 2018 1 次提交
  23. 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
  25. 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
  27. 01 12月, 2017 8 次提交
  29. 12 10月, 2017 1 次提交
  31. 21 9月, 2017 2 次提交
  33. 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
  35. 19 9月, 2017 2 次提交
    • H
      efi_selftest: provide an EFI selftest application · 623b3a57
      由 Heinrich Schuchardt 提交于 
      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: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      623b3a57
    • H
      efi_loader: rename __efi_hello_world_* · 5e44489b
      由 Heinrich Schuchardt 提交于 
      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: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      5e44489b