summaryrefslogtreecommitdiff
path: root/include/efi.h
AgeCommit message (Collapse)Author
2018-12-02efi_loader: typedef struct efi_object *efi_handle_tHeinrich Schuchardt
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 <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-23efi_loader: SPDX-License-Identifier for efi.hHeinrich Schuchardt
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 <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-08-30x86: zimage: Support booting Linux kernel from an EFI payloadBin Meng
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 <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-30efi: stub: Pass EFI system table address to U-Boot payloadBin 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 <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-21efi: Add EFI_MEMORY_{NV, MORE_RELIABLE, RO} attributesEugeniu Rosca
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 <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-08-21efi: Fix truncation of constant valueEugeniu 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 <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-07-25efi_loader: Introduce ms abi vararg helpersAlexander Graf
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 <agraf@suse.de>
2018-06-24efi.h: Do not use config optionsAlexander Graf
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 <agraf@suse.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: added some comments to describe the __x86_64__ check] Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-06-17efi: stub: Pass EFI GOP information to U-Boot payloadBin Meng
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 <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-06-14efi_loader: avoid initializer element is not constantHeinrich Schuchardt
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 <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-28efi: Conflict efi_loader with different stub bitnessAlexander Graf
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 <agraf@suse.de>
2017-12-01efi_loader: capitalize EFI_LOCATE_SEARCH_TYPE valuesHeinrich Schuchardt
Constants should be capitalized. So rename the values of enum efi_locate_search_type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-20efi_loader: efi variable supportRob 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: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-20efi_loader: add file/filesys supportRob 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 <robdclark@gmail.com> [agraf: whitespace fixes, unsigned fixes] Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-20part: move efi_guid_tRob Clark
Prep work for next patch. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-18efi_loader: fix typo in include/efi.hHeinrich Schuchardt
Fix typo in teh EFI_BOOT_SERVICES_CODE description. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2017-07-19efi_loader: define all known status codesxypron.glpk@gmx.de
efi.h held only a few EFI status codes. The patch adds the missing definitions for later usage. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-11-14x86: Tidy up selection of building the EFI stubSimon Glass
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 <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-19efi: Use asmlinkage for EFIAPISimon Glass
This is required for x86 and is also correct for ARM (since it is empty). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-09-07efi_loader: provide efi_mem_desc versionMian Yousaf Kaukab
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 <yousaf.kaukab@gmail.com>
2016-08-30x86: efi: Fix EFI 64-bit payload build warningsBin Meng
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 <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-08-30x86: efi: payload: Make EFI payload build againBin Meng
Since commit 73c5c39 "Makefile: Drop unnecessary -dtb suffixes", EFI payload does not build anymore. This fixes the build. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-03-15include/efi_api.h: Add more detailed API definitionsAlexander Graf
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 <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2015-08-05efi: Add 64-bit payload supportSimon Glass
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 <sjg@chromium.org> Improvements to how the payload is built: Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-05efi: Add support for loading U-Boot through an EFI stubSimon 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 <sjg@chromium.org> Improvements to how the payload is built: Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-05efi: Add start-up library codeSimon 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 <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
generated by cgit (git 2.34.1) at 2024-12-26 23:20:00 +0000