On Thu, 21 Nov 2024 at 19:44, Heinrich Schuchardt <[email protected]> wrote: > > On 21.11.24 15:01, Tom Rini wrote: > > On Thu, Nov 21, 2024 at 02:53:53PM +0100, Heinrich Schuchardt wrote: > >> On 30.08.24 13:45, Ilias Apalodimas wrote: > >>> The EFI_LOADER and EFI config options are randomly scattered under lib/ > >>> making it cumbersome to navigate and enable options, unless you really > >>> know what you are doing. On top of that the existing options are in > >>> random order instead of a logical one. > >>> > >>> So let's move things around a bit and move them under boot/. Present a > >>> generic UEFI entry where people can select Capsules, Protocols, > >>> Services, and an option to compile U-Boot as an EFI for X86 > >>> > >>> Signed-off-by: Ilias Apalodimas <[email protected]> > >>> --- > >>> Changes since v1: > >>> - Move the EFI Loader under boot/ instead of having it on the main menu > >>> - Fold in the U-Boot as an EFI app option under the new EFI menu > >>> boot/Kconfig | 2 + > >>> lib/Kconfig | 2 - > >>> lib/efi/Kconfig | 5 + > >>> lib/efi_loader/Kconfig | 204 +++++++++++++++++++++++------------------ > >>> 4 files changed, 124 insertions(+), 89 deletions(-) > >>> > >>> diff --git a/boot/Kconfig b/boot/Kconfig > >>> index 940389d4882f..a1477eb8c7e1 100644 > >>> --- a/boot/Kconfig > >>> +++ b/boot/Kconfig > >>> @@ -1,5 +1,7 @@ > >>> menu "Boot options" > >>> > >>> +source "lib/efi_loader/Kconfig" > >>> + > >>> menu "Boot images" > >>> > >>> config ANDROID_BOOT_IMAGE > >>> diff --git a/lib/Kconfig b/lib/Kconfig > >>> index 2059219a1207..06b4e9a73135 100644 > >>> --- a/lib/Kconfig > >>> +++ b/lib/Kconfig > >>> @@ -1081,8 +1081,6 @@ config SMBIOS_PARSER > >>> help > >>> A simple parser for SMBIOS data. > >>> > >>> -source "lib/efi/Kconfig" > >>> -source "lib/efi_loader/Kconfig" > >>> source "lib/optee/Kconfig" > >>> > >>> config TEST_FDTDEC > >>> diff --git a/lib/efi/Kconfig b/lib/efi/Kconfig > >>> index c2b9bb73f718..81ed3e66b34d 100644 > >>> --- a/lib/efi/Kconfig > >>> +++ b/lib/efi/Kconfig > >>> @@ -1,3 +1,6 @@ > >>> +menu "U-Boot as UEFI application" > >>> + depends on X86 > >>> + > >>> config EFI > >>> bool "Support running U-Boot from EFI" > >>> depends on X86 > >>> @@ -72,3 +75,5 @@ config EFI_RAM_SIZE > >>> use. U-Boot allocates this from EFI on start-up (along with a few > >>> other smaller amounts) and it can never be increased after that. > >>> It is used as the RAM size in with U-Boot. > >>> + > >>> +endmenu > >>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > >>> index 6ffefa9103ff..0756be61d688 100644 > >>> --- a/lib/efi_loader/Kconfig > >>> +++ b/lib/efi_loader/Kconfig > >>> @@ -1,3 +1,5 @@ > >>> +menu "UEFI Support" > >>> + > >>> config EFI_LOADER > >>> bool "Support running UEFI applications" > >>> depends on OF_LIBFDT && ( \ > >>> @@ -41,13 +43,58 @@ config EFI_BINARY_EXEC > >>> You may enable CMD_BOOTEFI_BINARY so that you can use bootefi > >>> command to do that. > >>> > >>> -config EFI_BOOTMGR > >>> - bool "UEFI Boot Manager" > >>> +config EFI_SECURE_BOOT > >>> + bool "Enable EFI secure boot support" > >>> + depends on EFI_LOADER && FIT_SIGNATURE > >>> + select HASH > >>> + select SHA256 > >>> + select RSA > >>> + select RSA_VERIFY_WITH_PKEY > >>> + select IMAGE_SIGN_INFO > >>> + select ASYMMETRIC_KEY_TYPE > >>> + select ASYMMETRIC_PUBLIC_KEY_SUBTYPE > >>> + select X509_CERTIFICATE_PARSER > >>> + select PKCS7_MESSAGE_PARSER > >>> + select PKCS7_VERIFY > >>> + select MSCODE_PARSER > >>> + select EFI_SIGNATURE_SUPPORT > >>> + help > >>> + Select this option to enable EFI secure boot support. > >>> + Once SecureBoot mode is enforced, any EFI binary can run only if > >>> + it is signed with a trusted key. To do that, you need to install, > >>> + at least, PK, KEK and db. > >>> + > >>> +config EFI_SIGNATURE_SUPPORT > >>> + bool > >>> + > >>> +menu "UEFI services" > >>> + > >>> +config EFI_GET_TIME > >>> + bool "GetTime() runtime service" > >>> + depends on DM_RTC > >>> default y > >>> help > >>> - Select this option if you want to select the UEFI binary to be > >>> booted > >>> - via UEFI variables Boot####, BootOrder, and BootNext. You should > >>> also > >>> - normally enable CMD_BOOTEFI_BOOTMGR so that the command is > >>> available. > >>> + Provide the GetTime() runtime service at boottime. This service > >>> + can be used by an EFI application to read the real time clock. > >>> + > >>> +config EFI_SET_TIME > >>> + bool "SetTime() runtime service" > >>> + depends on EFI_GET_TIME > >>> + default y if ARCH_QEMU || SANDBOX > >>> + help > >>> + Provide the SetTime() runtime service at boottime. This service > >>> + can be used by an EFI application to adjust the real time clock. > >>> + > >>> +config EFI_HAVE_RUNTIME_RESET > >>> + # bool "Reset runtime service is available" > >>> + bool > >>> + default y > >>> + depends on ARCH_BCM283X || FSL_LAYERSCAPE || PSCI_RESET || \ > >>> + SANDBOX || SYSRESET_SBI || SYSRESET_X86 > >>> + > >>> +endmenu > >>> + > >>> +menu "UEFI Variables" > >>> > >>> choice > >>> prompt "Store for non-volatile UEFI variables" > >>> @@ -172,30 +219,18 @@ config EFI_VAR_BUF_SIZE > >>> > >>> Minimum 4096, default 131072 > >>> > >>> -config EFI_GET_TIME > >>> - bool "GetTime() runtime service" > >>> - depends on DM_RTC > >>> - default y > >>> +config EFI_PLATFORM_LANG_CODES > >>> + string "Language codes supported by firmware" > >>> + default "en-US" > >>> help > >>> - Provide the GetTime() runtime service at boottime. This service > >>> - can be used by an EFI application to read the real time clock. > >>> + 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. > >>> > >>> -config EFI_SET_TIME > >>> - bool "SetTime() runtime service" > >>> - depends on EFI_GET_TIME > >>> - default y if ARCH_QEMU || SANDBOX > >>> - help > >>> - Provide the SetTime() runtime service at boottime. This service > >>> - can be used by an EFI application to adjust the real time clock. > >>> +endmenu > >>> > >>> -config EFI_SCROLL_ON_CLEAR_SCREEN > >>> - bool "Avoid overwriting previous output on clear screen" > >>> - help > >>> - Instead of erasing the screen content when the console screen should > >>> - be cleared, emit blank new lines so that previous output is scrolled > >>> - out of sight rather than overwritten. On serial consoles this allows > >>> - to capture complete boot logs (except for interactive menus etc.) > >>> - and can ease debugging related issues. > >>> +menu "Capsule support" > >>> > >>> config EFI_HAVE_CAPSULE_SUPPORT > >>> bool > >>> @@ -309,6 +344,10 @@ config EFI_CAPSULE_CRT_FILE > >>> embedded in the platform's device tree and used for capsule > >>> authentication at the time of capsule update. > >>> > >>> +endmenu > >>> + > >>> +menu "UEFI protocol support" > >>> + > >>> config EFI_DEVICE_PATH_TO_TEXT > >>> bool "Device path to text protocol" > >>> default y > >>> @@ -362,39 +401,6 @@ config EFI_UNICODE_CAPITALIZATION > >>> > >>> endif > >>> > >>> -config EFI_LOADER_BOUNCE_BUFFER > >>> - bool "EFI Applications use bounce buffers for DMA operations" > >>> - 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. > >>> - > >>> -config EFI_PLATFORM_LANG_CODES > >>> - string "Language codes supported by firmware" > >>> - 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. > >>> - > >>> -config EFI_HAVE_RUNTIME_RESET > >>> - # bool "Reset runtime service is available" > >>> - bool > >>> - default y > >>> - depends on ARCH_BCM283X || FSL_LAYERSCAPE || PSCI_RESET || \ > >>> - SANDBOX || SYSRESET_SBI || SYSRESET_X86 > >>> - > >>> -config EFI_GRUB_ARM32_WORKAROUND > >>> - bool "Workaround for GRUB on 32bit ARM" > >>> - default n if ARCH_BCM283X || ARCH_SUNXI || ARCH_QEMU > >>> - default y > >>> - depends on ARM && !ARM64 > >>> - help > >>> - GRUB prior to version 2.04 requires U-Boot to disable caches. This > >>> - workaround currently is also needed on systems with caches that > >>> - cannot be managed via CP15. > >>> - > >>> config EFI_RNG_PROTOCOL > >>> bool "EFI_RNG_PROTOCOL support" > >>> depends on DM_RNG > >>> @@ -447,29 +453,36 @@ config EFI_LOAD_FILE2_INITRD > >>> installed and Linux 5.7+ will ignore any initrd=<ramdisk> command > >>> line > >>> argument. > >>> > >>> -config EFI_SECURE_BOOT > >>> - bool "Enable EFI secure boot support" > >>> - depends on EFI_LOADER && FIT_SIGNATURE > >>> - select HASH > >>> - select SHA256 > >>> - select RSA > >>> - select RSA_VERIFY_WITH_PKEY > >>> - select IMAGE_SIGN_INFO > >>> - select ASYMMETRIC_KEY_TYPE > >>> - select ASYMMETRIC_PUBLIC_KEY_SUBTYPE > >>> - select X509_CERTIFICATE_PARSER > >>> - select PKCS7_MESSAGE_PARSER > >>> - select PKCS7_VERIFY > >>> - select MSCODE_PARSER > >>> - select EFI_SIGNATURE_SUPPORT > >>> +config EFI_RISCV_BOOT_PROTOCOL > >>> + bool "RISCV_EFI_BOOT_PROTOCOL support" > >>> + default y > >>> + depends on RISCV > >>> help > >>> - Select this option to enable EFI secure boot support. > >>> - Once SecureBoot mode is enforced, any EFI binary can run only if > >>> - it is signed with a trusted key. To do that, you need to install, > >>> - at least, PK, KEK and db. > >>> + The EFI_RISCV_BOOT_PROTOCOL is used to transfer the boot hart ID > >>> + to the next boot stage. It should be enabled as it is meant to > >>> + replace the transfer via the device-tree. The latter is not > >>> + possible on systems using ACPI. > >>> > >>> -config EFI_SIGNATURE_SUPPORT > >>> - bool > >>> +endmenu > >>> + > >>> +menu "Misc options" > >>> +config EFI_LOADER_BOUNCE_BUFFER > >>> + bool "EFI Applications use bounce buffers for DMA operations" > >>> + depends on ARM64 > >> > >> Hello Ilias, > >> > >> your merged patch revoked > >> > >> dcd1b63b7072 ("efi_loader: allow EFI_LOADER_BOUNCE_BUFFER on all > >> architectures") > >> > >> which we need to fix problems on JH7110 boards with more than 4 GiB. > >> > >> We need to add the revoked patch again. > >> > > > > Can we do that as a "today" solution, and make EFI_LOADER_BOUNCE_BUFFER > > disappear and just be enabled by BOUNCE_BUFFER for v2025.04 please? > > > > As discussed with Simon the implementation of a bounce buffer should > only exist in the block device layer and not in the UEFI sub-system. We > should strive to make that change with the April release. > > But as off today JH7110 board with more than 4 GiB fail to boot without > this setting.
Also, another thing to check (probably with respective board maintainers) would be if we can remove the ram_top restriction on jh7110 boards. There is a comment in arch/riscv/cpu/jh7110/dram.c that the ram_top limit is to get 32 bit DMA capable devices to work. But that should not be an issue with bounce buffers enabled? -sughosh > > Best regards > > Heinrich
