brain-hackers_pepepper-mirror
/
u-boot-brain
mirror of https://github.com/brain-hackers/u-boot-brain
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
u-boot-brain/lib/efi_loader/Kconfig

59 lines
2.1 KiB
Plaintext
Raw Normal View History

efi_loader: hook up in build environment Now that we have all the bits and pieces ready for EFI payload loading support, hook them up in Makefiles and KConfigs so that we can build. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [trini: Enable only when we of OF_LIBFDT, disable on kwb and colibri_pxa270] Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-04 09:10:07 +09:00
config EFI_LOADER
bool "Support running EFI Applications in U-Boot"
efi: sandbox: Enable EFI loader build for sandbox This allows this feature to build within sandbox. This is useful for testing. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-15 15:50:53 +09:00
depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT
efi: Conflict efi_loader with different stub bitness 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>
2018-01-24 22:54:21 +09:00
# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
efi_loader: hook up in build environment Now that we have all the bits and pieces ready for EFI payload loading support, hook them up in Makefiles and KConfigs so that we can build. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [trini: Enable only when we of OF_LIBFDT, disable on kwb and colibri_pxa270] Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-04 09:10:07 +09:00
default y
Convert LIB_UUID to Kconfig config_fallback.h has some logic that checks a variety of options and selects LIB_UUID if it hasn't already been selected. This will all LIB_UUID in Kconfig and select this option for the list of options to allow us to remove the logic from fallbacks Signed-off-by: Adam Ford <aford173@gmail.com>
2018-02-07 03:14:28 +09:00
select LIB_UUID
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com>
2018-02-07 03:43:56 +09:00
select HAVE_BLOCK_DEVICE
efi_loader: GetNextVariableName() relies on REGEX Our implementation of GetNextVariableName() relies on CONFIG_REGEX=y. So EFI_LOADER has to select it. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2019-01-23 05:35:23 +09:00
select REGEX
efi_loader: if EFI_LOADER is enabled, enable CFB_CONSOLE_ANSI EFI applications like GRUB issue ANSI sequences for setting colors and for positioning. So if the EFI subsystem is enabled, we should also enable ANSI control sequences by default. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-04-30 06:37:12 +09:00
imply CFB_CONSOLE_ANSI
efi_loader: hook up in build environment Now that we have all the bits and pieces ready for EFI payload loading support, hook them up in Makefiles and KConfigs so that we can build. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [trini: Enable only when we of OF_LIBFDT, disable on kwb and colibri_pxa270] Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-04 09:10:07 +09:00
help
Select this option if you want to run EFI applications (like grub2)
on top of U-Boot. If this option is enabled, U-Boot will expose EFI
interfaces to a loaded EFI application, enabling it to reuse U-Boot's
device drivers.
efi_loader: Add bounce buffer support Some hardware that is supported by U-Boot can not handle DMA above 32bits. For these systems, we need to come up with a way to expose the disk interface in a safe way. This patch implements EFI specific bounce buffers. For non-EFI cases, this apparently was no issue so far, since we can just define our environment variables conveniently. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-05-12 01:25:48 +09:00
lib: charset: upper/lower case conversion Provide functions for upper and lower case conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-05 02:34:56 +09:00
config EFI_UNICODE_CAPITALIZATION
bool "Support Unicode capitalization"
depends on EFI_LOADER
default y
help
Select this option to enable correct handling of the capitalization of
Unicode codepoints in the range 0x0000-0xffff. If this option is not
set, only the the correct handling of the letters of the codepage
used by the FAT file system is ensured.
efi_loader: fix setting PlatformLang The UEFI variables PlatformLang and PlatformLangCodes specify the current firmware language and the list of all available languages. Currently their values are hard coded. With the patch a new configuration variable EFI_PLATFORM_LANG_CODES is provided. When initializing the UEFI subsystem this configuration variable is used to initialize PlatformLangCodes. The value of variable PlatformLang is read. If it is not set, the first language specified in EFI_PLATFORM_LANG_CODES is used to initialize PlatformLang. Suggested-by: Takahiro Akashi <takahiro.akashi@linaro.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-04-11 14:34:24 +09:00
config EFI_PLATFORM_LANG_CODES
string "Language codes supported by firmware"
depends on EFI_LOADER
default "en-US"
help
This value is used to initialize the PlatformLangCodes variable. Its
value is a semicolon (;) separated list of language codes in native
RFC 4646 format, e.g. "en-US;de-DE". The first language code is used
to initialize the PlatformLang variable.
efi_loader: Add bounce buffer support Some hardware that is supported by U-Boot can not handle DMA above 32bits. For these systems, we need to come up with a way to expose the disk interface in a safe way. This patch implements EFI specific bounce buffers. For non-EFI cases, this apparently was no issue so far, since we can just define our environment variables conveniently. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-05-12 01:25:48 +09:00
config EFI_LOADER_BOUNCE_BUFFER
bool "EFI Applications use bounce buffers for DMA operations"
depends on EFI_LOADER && ARM64
default n
help
Some hardware does not support DMA to full 64bit addresses. For this
hardware we can create a bounce buffer so that payloads don't have to
worry about platform details.
efi_loader: Make HII a config option Heinrich ran into issues with HII and iPXE which lead to #SErrors on his Odroid-C2 system. We definitely do not want to regress just yet, so let's not expose the HII protocols by default. Instead, let's make it a config option that people can play with This way, we can stabilize the code in tree without breaking any users. Once someone figures out, why this breaks iPXE (probably a NULL dereference), we can enable it by default. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> --- v1 -> v2: - Remove HII selftest as well v2 -> v3: - Make config option
2019-02-11 23:24:00 +09:00
config EFI_LOADER_HII
bool "Expose HII protocols to EFI applications"
depends on EFI_LOADER
efi_loader: enable HII protocols by default As the UEFI shell requires the HII protocols let's enable them by default. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-04-08 06:58:50 +09:00
default y
efi_loader: Make HII a config option Heinrich ran into issues with HII and iPXE which lead to #SErrors on his Odroid-C2 system. We definitely do not want to regress just yet, so let's not expose the HII protocols by default. Instead, let's make it a config option that people can play with This way, we can stabilize the code in tree without breaking any users. Once someone figures out, why this breaks iPXE (probably a NULL dereference), we can enable it by default. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> --- v1 -> v2: - Remove HII selftest as well v2 -> v3: - Make config option
2019-02-11 23:24:00 +09:00
help
The Human Interface Infrastructure is a complicated framework that
allows UEFI applications to draw fancy menus and hook strings using
a translation framework.
U-Boot implements enough of its features to be able to run the UEFI
efi_loader: enable HII protocols by default As the UEFI shell requires the HII protocols let's enable them by default. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-04-08 06:58:50 +09:00
Shell, but not more than that.