| Age | Commit message (Collapse) | Author |
|---|
|
Add a missing colon ':' to match Sphinx style.
Reviewed-by: Bin Meng <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Since C99 flexible array members are allowed at the end of structures.
We require C11.
Use struct efi_gop_mode_info in the definition of struct efi_entry_gopmode
to avoid code duplication and unnecessary conversions.
Reviewed-by: Bin Meng <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The EFI HTTP boot puts the ISO installer image at some location in
memory. Information about this image has to be passed on to the OS
kernel, which is done by adding a persistent memory(pmem) node to the
devicetree(DT) that is passed to the OS. The OS kernel then gets
information about the presence of this ISO image and proceeds with the
installation.
In U-Boot, this ISO image gets mounted as a memory mapped blkmap
device slice, with the 'preserve' attribute. Add a helper function
which iterates through all such slices, and invokes a callback. The
callback adds the pmem node to the DT and removes the corresponding
memory region from the EFI memory map. Invoke this helper function as
part of the DT fixup which happens before booting the OS.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Tobias Waldekranz <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
* add EFI_MEMORY_CPU_CRYPTO, EFI_MEMORY_HOT_PLUGGABLE
* correct output for EFI_MEMORY_XP
* remove duplicate list entry for EFI_MEMORY_UC
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Fix 'indicatged' and 'adress' typos.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
When the --native flag is given, pretend to be running the host
architecture rather than sandbox.
Allow the same control for PXE too.
Signed-off-by: Simon Glass <[email protected]>
|
|
Move this function from the EFI bootmeth to the common efi_helper file.
No functional change is intended.
Signed-off-by: Simon Glass <[email protected]>
|
|
Use a function to obtain the device EFI filename, so that we can control
how sandbox behaves.
Signed-off-by: Simon Glass <[email protected]>
|
|
This let's us forward declare efi_guid_t in the UUID code without
pulling in efi.h
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Move the guidcmp() and guidcpy() functions to efi.h, near the definition of
the efi_guid_t type those functions deal with.
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
|
|
We don't yet support EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS for file
based variables, but we should pass it to TEE based variable stores.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
GetVariable() and SetVariable() use an uint32_t value for attributes.
The UEFI specification defines the related constants as 32bit.
Add the missing EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS constant.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
This code is used with EFI_LOADER but is also useful (with some
modifications) for the EFI app and payload. Move it into a shared
file.
Show the address of the table so it can be examined if needed. Also show
the table name as unknown if necessary. Our list of GUIDs is fairly
small.
Signed-off-by: Simon Glass <[email protected]>
|
|
Avoid forward declaration of struct efi_device_path.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Current U-Boot implements 64-bit boundary for efi_guid_t structure.
It follows the UEFI specification, page 21 of the UEFI Specification v2.10
says about EFI_GUID:
128-bit buffer containing a unique identifier value. Unless
otherwise specified, aligned on a 64-bit boundary.
On the other hand, page 163 of the UEFI specification v2.10 and
EDK2 reference implementation both define EFI_GUID as
struct { u32 a; u16; b; u16 c; u8 d[8]; }; and so the implied
alignment is 32-bit not 64-bit like U-Boot efi_guid_t.
Due to this alignment difference, EDK2 application "CapsuleApp.efi -P"
does not work as expected.
This calls EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImageInfo()
and dump the EFI_FIRMWARE_IMAGE_DESCRIPTOR structure,
offsetof(EFI_FIRMWARE_IMAGE_DESCRIPTOR, ImageTypeId) is different,
8 in U-Boot and 4 in EDK2(CapsuleApp.efi).
Here is the wrong EFI_GUID dump.
wrong dump : ImageTypeId - 00000000-7D83-058B-D550-474CA19560D8
expected : ImageTypeId - 058B7D83-50D5-4C47-A195-60D86AD341C4
EFI_FIRMWARE_IMAGE_DESCRIPTOR structure is defined in UEFI specification:
typedef struct {
UINT8 ImageIndex;
EFI_GUID ImageTypeId;
UINT64 ImageId
<snip>
} EFI_FIRMWARE_IMAGE_DESCRIPTOR;
There was the relevant patch for linux kernel to use 32-bit alignment
for efi_guid_t [1].
U-Boot should get aligned to EDK2 reference implementation and
linux kernel.
Due to this alignment change, efi_hii_ref structure in include/efi_api.h
is affected, but it is not used in the current U-Boot code.
[1] https://lore.kernel.org/all/[email protected]/
Cc: Ilias Apalodimas <[email protected]>
Signed-off-by: Masahisa Kojima <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
A following patch is cleaning up the core EFI code trying to remove
sequences of efi_create_handle, efi_add_protocol.
Although this works fine there's a problem with the latter since it is
usually combined with efi_delete_handle() which blindly removes all
protocols on a handle and deletes the handle. We should try to adhere to
the EFI spec which only deletes a handle if the last instance of a protocol
has been removed. Another problem is that efi_delete_handle() never checks
for opened protocols, but the EFI spec defines that the caller is
responsible for ensuring that there are no references to a protocol
interface that is going to be removed.
So let's fix this by replacing all callsites of
efi_create_handle(), efi_add_protocol() , efi_delete_handle() with
Install/UninstallMultipleProtocol.
In order to do that redefine functions that can be used by the U-Boot
proper internally and add '_ext' variants that will be used from the
EFI API
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Document the return value in efi_init(). Fix up @sizep in efi_info_get().
Use Return: instead of @return
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
At present the 'efi' command only works in the EFI payload. Update it to
work in the app too, so the memory map can be examined.
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
At present this function requires a pointer to struct efi_entry_memmap
but the only field used in there is the desc_size. We want to be able
to use it from the app, so update it to use desc_size directly.
Signed-off-by: Simon Glass <[email protected]>
|
|
At present this code is inline in the app and stub. But they do the same
thing. The difference is that the stub does it immediately and the app
doesn't want to do it until the end (when it boots a kernel) or not at
all, if returning to UEFI.
Move it into a function so it can be called as needed.
Add a comment showing how to store the memory map so that it can be
accessed within the app if needed, for debugging purposes only. The map
can change without notice.
Signed-off-by: Simon Glass <[email protected]>
|
|
This provides access to EFI tables after U-Boot has exited boot services.
It is not needed in the app since boot services remain alive and we can
just call them whenever needed.
Add a comment to explain this.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
At present each of these has its own static variable and helper functions.
Move them into a shared file.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
This structure is uncommented. Fix it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This is not used anywhere drop it.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
When starting the app, locate all block devices and make them available
to U-Boot. This allows listing partitions and accessing files in
filesystems.
EFI also has the concept of 'disks', meaning boot media. For now, this
is not obviously useful in U-Boot, but add code to at least locate these.
This can be expanded later as needed.
We cannot use printf() in the early stub or app since it is not compiled
in
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Add missing colon.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Add a block driver which handles read/write for EFI block devices. This
driver actually already exists ('efi_block') but is not really suitable
for use as a real U-Boot driver:
- The operations do not provide a udevice
- The code is designed for running as part of EFI loader, so uses
EFI_PRINT() and EFI_CALL().
- The bind method probes the device, which is not permitted
- It uses 'EFI' as its parent device
The new driver is more 'normal', just requiring its platform data be set
up in advance.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Add a function to return this information along with a stub for the
efi_info_get() function, since calling it otherwise hangs U-Boot.
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Use the same name as in the UEFI specification to avoid confusion.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
For type checking we need an enum.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
* UEFI spec 2.9 introduced a new memory type EFI_UNACCEPTED_MEMORY_TYPE.
Add it to enum EFI_MEMORY_TYPE.
* Add missing EFI_MEMORY_CPU_CRYPTO constant
* Improve description of EFI_PERSISTENT_MEMORY_TYPE
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Move efi_intn_t and efi_uintn_t to include/efi.h to allow usage without
efi_api.h
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
* Eliminate superfluous enum value EFI_TABLE_END.
* Use correct variable type for the memory type.
* Check validity of memory type.
* Make efi_build_mem_table static.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The UEFI 2.8 specification has introduced the EFI_MEMORY_SP memory
attribute. Add it to the 'efidebug memmap' and 'efi mem' commands.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Of all warning status codes up to now only EFI_WARN_DELETE_FAILURE is
defined.
The patch adds the missing definitions for later usage.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The UEFI specification prescribes that AllocatePages() checks the memory
type.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
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 <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
Add the missing SPDX-License-Identifier based on Linux kernel commit
b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to
files with no license").
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Eugeniu Rosca <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Eugeniu Rosca <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
Tested-by: Bin Meng <[email protected]>
[bmeng: added some comments to describe the __x86_64__ check]
Signed-off-by: Bin Meng <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
If UEFI BIOS has the graphics output protocol (GOP), let's pass its
information to U-Boot payload so that U-Boot can utilize it (eg:
an EFI framebuffer driver).
Signed-off-by: Bin Meng <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
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 <[email protected]>
|
|
Constants should be capitalized.
So rename the values of enum efi_locate_search_type.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
