08 Jan, 2020

1 commit


23 Apr, 2019

1 commit


13 Apr, 2019

1 commit

  • There are Cubox-i machines out there with nearly 4 GiB of RAM. The
    RAM starts at 0x10000000 with a size of 0xf0000000. Thus the end
    of RAM is at 0x100000000. This overflows a 32-bit integer, which
    should be fine since in the EFI memory code the variables used are
    all 64-bit with a fixed size. Unfortunately EFI_PAGE_MASK, which is
    used in the EFI memory code to remove the lower bits, is based on
    the EFI_PAGE_SIZE macro which, uses 1UL with a shift. This means
    the resulting mask is UL, which is only 32-bit on ARMv7. Use ULL to
    make sure that even on 32-bit platforms we use a 64-bit long mask.
    Without this there will be no memory available in the EFI memory map
    and bootefi will fail allocating pages.

    Signed-off-by: Patrick Wildt
    Reviewed-by: Heinrich Schuchardt
    Reviewed-by: Patrick Delaunay

    Patrick Wildt
     

13 Feb, 2019

1 commit

  • The UEFI Specification Version 2.7 Errata A defines:

    "EFI_GUID
    128-bit buffer containing a unique identifier value.
    Unless otherwise specified, aligned on a 64-bit boundary."

    Before this patch efi_guid_t was 8-bit aligned.

    Signed-off-by: Heinrich Schuchardt
    Acked-by: Ard Biesheuvel
    Signed-off-by: Alexander Graf

    Heinrich Schuchardt
     

03 Dec, 2018

1 commit

  • All our handles point to a struct efi_object. So let's define the
    efi_handle_t accordingly. This helps us to discover coding errors much
    more easily. This becomes evident by the corrections to the usage of
    handles in this patch.

    Rename variable image_handle to image_obj where applicable.

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

    Heinrich Schuchardt
     

24 Sep, 2018

1 commit


30 Aug, 2018

2 commits

  • At present Linux kernel loaded from U-Boot as an EFI payload does
    not boot. This fills in kernel's boot params structure with the
    required critical EFI information like system table address and
    memory map stuff so that kernel can obtain essential data like
    runtime services and ACPI table to boot.

    With this patch, now U-Boot as an EFI payload becomes much more
    practical: it is another option of kernel bootloader, ie, can be
    a replacement for grub.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • This updates the EFI stub codes to pass UEFI BIOS's system table
    address to U-Boot payload so that U-Boot can utilize it.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     

21 Aug, 2018

2 commits

  • With this update, the memory attributes are in sync with Linux
    kernel v4.18-rc4. They also match page 190 of UEFI 2.7 spec [1].

    [1] http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf

    Suggested-by: Heinrich Schuchardt
    Signed-off-by: Eugeniu Rosca
    Reviewed-by: Heinrich Schuchardt
    Signed-off-by: Alexander Graf

    Eugeniu Rosca
     
  • Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"),
    sparse constantly complains about truncated constant value in efi.h:

    include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0)

    This can get quite noisy, preventing real issues to be noticed:

    $ make defconfig
    *** Default configuration is based on 'sandbox_defconfig'
    $ make C=2 -j12 2>&1 | grep truncates | wc -l
    441

    After the patch is applied:
    $ make C=2 -j12 2>&1 | grep truncates | wc -l
    0
    $ sparse --version
    v0.5.2

    Following the suggestion of Heinrich Schuchardt, instead of only
    fixing the root-cause, I replaced the whole enum of _SHIFT values
    by ULL defines. This matches both the UEFI 2.7 spec and the Linux
    kernel implementation.

    Some ELF size comparison before and after the patch (gcc 7.3.0):

    efi-x86_payload64_defconfig:
    text data bss dec hex filename
    407174 29432 278676 715282 aea12 u-boot.old
    407152 29464 278676 715292 aea1c u-boot.new
    -22 +32 0 +10

    efi-x86_payload32_defconfig:
    text data bss dec hex filename
    447075 30308 280076 757459 b8ed3 u-boot.old
    447053 30340 280076 757469 b8edd u-boot.new
    -22 +32 0 +10

    Fixes: 867a6ac86dd8 ("efi: Add start-up library code")
    Suggested-by: Heinrich Schuchardt
    Signed-off-by: Eugeniu Rosca
    Reviewed-by: Heinrich Schuchardt
    Reviewed-by: Heinrich Schuchardt
    Signed-off-by: Alexander Graf

    Eugeniu Rosca
     

25 Jul, 2018

1 commit

  • Varargs differ between sysv and ms abi. On x86_64 we have to follow the ms
    abi though, so we also need to make sure we use x86_64 varargs helpers.

    This patch introduces generic efi vararg helpers that adhere to the
    respective EFI ABI. That way we can deal with them properly from efi
    loader code and properly interpret variable arguments.

    This fixes the InstallMultipleProtocolInterfaces tests in the efi selftests
    on x86_64 for me.

    Signed-off-by: Alexander Graf

    Alexander Graf
     

24 Jun, 2018

1 commit

  • Currently efi.h determines a few bits of its environment according to
    config options. This falls apart with the efi stub support which may
    result in efi.h getting pulled into the stub as well as real U-Boot
    code. In that case, one may be 32bit while the other one is 64bit.

    This patch changes the conditionals to use compiler provided defines
    instead. That way we always adhere to the build environment we're in
    and the definitions adjust automatically.

    Signed-off-by: Alexander Graf
    Reviewed-by: Bin Meng
    Tested-by: Bin Meng
    [bmeng: added some comments to describe the __x86_64__ check]
    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Alexander Graf
     

17 Jun, 2018

1 commit


14 Jun, 2018

1 commit

  • When building with -pedantic the current definition of EFI_GUID() causes
    an error 'initializer element is not constant'.

    Currently EFI_GUID() is used both as an anonymous constant and as an
    intializer. A conversion to efi_guid_t is not allowable when using
    EFI_GUID() as an initializer. But it is needed when using it as an
    anonymous constant.

    We should not use EFI_GUID() for anything but an initializer. So let's
    introduce a variable where needed and remove the conversion.

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

    Heinrich Schuchardt
     

29 Jan, 2018

1 commit

  • 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

    Alexander Graf
     

01 Dec, 2017

1 commit


20 Sep, 2017

3 commits

  • 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

    Rob Clark
     
  • 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
    [agraf: whitespace fixes, unsigned fixes]
    Signed-off-by: Alexander Graf

    Rob Clark
     
  • Prep work for next patch.

    Signed-off-by: Rob Clark
    Reviewed-by: Heinrich Schuchardt
    Signed-off-by: Alexander Graf

    Rob Clark
     

19 Sep, 2017

1 commit


19 Jul, 2017

1 commit


15 Nov, 2016

1 commit

  • 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
    Reviewed-by: Bin Meng
    Signed-off-by: Alexander Graf

    Simon Glass
     

19 Oct, 2016

1 commit


07 Sep, 2016

1 commit

  • 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

    Mian Yousaf Kaukab
     

30 Aug, 2016

2 commits

  • 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
    Reviewed-by: Simon Glass

    Bin Meng
     
  • Since commit 73c5c39 "Makefile: Drop unnecessary -dtb suffixes",
    EFI payload does not build anymore. This fixes the build.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     

16 Mar, 2016

1 commit

  • 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
    Reviewed-by: Simon Glass
    Tested-by: Simon Glass

    Alexander Graf
     

05 Aug, 2015

3 commits

  • 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
    Improvements to how the payload is built:
    Signed-off-by: Bin Meng
    Reviewed-by: Bin Meng
    Tested-by: Bin Meng

    Simon Glass
     
  • 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
    Improvements to how the payload is built:
    Signed-off-by: Bin Meng
    Reviewed-by: Bin Meng
    Tested-by: Bin Meng

    Simon Glass
     
  • 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
    Reviewed-by: Bin Meng

    Simon Glass