| Message ID | 20240814134518.82692-1-ilias.apalodimas@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Kconfig: clean up the efi configuration status | expand |
Hi Ilias, On Wed, 14 Aug 2024 at 07:45, Ilias Apalodimas <ilias.apalodimas@linaro.org> 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 present two enties for the entries > EFI_LOADER and EFI options in the main config screen. > While at it add menus for Capsules, Protocols, and Services in the > EFI_LOADER so people can find their way around easier > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> > --- > Kconfig | 4 + > lib/Kconfig | 2 - > lib/efi/Kconfig | 5 + > lib/efi_loader/Kconfig | 202 +++++++++++++++++++++++------------------ > 4 files changed, 123 insertions(+), 90 deletions(-) > > diff --git a/Kconfig b/Kconfig > index 82df59f176ec..62c5441e3576 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -756,3 +756,7 @@ source "lib/Kconfig" > source "test/Kconfig" > > source "tools/Kconfig" > + > +source "lib/efi_loader/Kconfig" > + This should be included from boot/Kconfig as it relates to booting. The EFI app thing should perhaps be under there too...I'm not sure. Regards, Simon
On Thu, Aug 15, 2024, 23:33 Simon Glass <sjg@chromium.org> wrote: > Hi Ilias, > > On Wed, 14 Aug 2024 at 07:45, Ilias Apalodimas > <ilias.apalodimas@linaro.org> 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 present two enties for the > > entries > > > EFI_LOADER and EFI options in the main config screen. > > While at it add menus for Capsules, Protocols, and Services in the > > EFI_LOADER so people can find their way around easier > > > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > --- > > Kconfig | 4 + > > lib/Kconfig | 2 - > > lib/efi/Kconfig | 5 + > > lib/efi_loader/Kconfig | 202 +++++++++++++++++++++++------------------ > > 4 files changed, 123 insertions(+), 90 deletions(-) > > > > diff --git a/Kconfig b/Kconfig > > index 82df59f176ec..62c5441e3576 100644 > > --- a/Kconfig > > +++ b/Kconfig > > @@ -756,3 +756,7 @@ source "lib/Kconfig" > > source "test/Kconfig" > > > > source "tools/Kconfig" > > + > > +source "lib/efi_loader/Kconfig" > > + > > This should be included from boot/Kconfig as it relates to booting. > Hmm why? Booting is one of the things efi does. I prefer having it on the main menu since it's a pointer to the entire spec, protocols, services etc > The EFI app thing should perhaps be under there too...I'm not sure. > I was toying around with the idea as well. But eventually I decided this needs it's own entry since it's about building U-Boot as a pe/coff. I don't mind changing this though. Thanks Ilias > > Regards, > Simon >
Hi Ilias, On Thu, 15 Aug 2024 at 15:11, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > > > On Thu, Aug 15, 2024, 23:33 Simon Glass <sjg@chromium.org> wrote: >> >> Hi Ilias, >> >> On Wed, 14 Aug 2024 at 07:45, Ilias Apalodimas >> <ilias.apalodimas@linaro.org> 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 present two enties for the >> >> entries >> >> > EFI_LOADER and EFI options in the main config screen. >> > While at it add menus for Capsules, Protocols, and Services in the >> > EFI_LOADER so people can find their way around easier >> > >> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> >> > --- >> > Kconfig | 4 + >> > lib/Kconfig | 2 - >> > lib/efi/Kconfig | 5 + >> > lib/efi_loader/Kconfig | 202 +++++++++++++++++++++++------------------ >> > 4 files changed, 123 insertions(+), 90 deletions(-) >> > >> > diff --git a/Kconfig b/Kconfig >> > index 82df59f176ec..62c5441e3576 100644 >> > --- a/Kconfig >> > +++ b/Kconfig >> > @@ -756,3 +756,7 @@ source "lib/Kconfig" >> > source "test/Kconfig" >> > >> > source "tools/Kconfig" >> > + >> > +source "lib/efi_loader/Kconfig" >> > + >> >> This should be included from boot/Kconfig as it relates to booting. > > > Hmm why? Booting is one of the things efi does. I prefer having it on the main menu since it's a pointer to the entire spec, protocols, services etc True. From a functionality point of view, there is booting and firmware update. Is there anything else? I have thought for a while that we should perhaps have an 'update' menu. Where, for example, would VBE fit in the menus? > > >> >> The EFI app thing should perhaps be under there too...I'm not sure. > > > I was toying around with the idea as well. But eventually I decided this needs it's own entry since it's about building U-Boot as a pe/coff. I don't mind changing this though. Yes, building as an app isn't really about booting. It looks very lonely at the end of the menu, though. Regards, Simon > > Thanks > Ilias >> >> >> Regards, >> Simon
Hi Simon On mobile apologies for any weird formatting in advance. On Fri, Aug 16, 2024, 04:34 Simon Glass <sjg@chromium.org> wrote: > Hi Ilias, > > On Thu, 15 Aug 2024 at 15:11, Ilias Apalodimas > <ilias.apalodimas@linaro.org> wrote: > > > > > > > > On Thu, Aug 15, 2024, 23:33 Simon Glass <sjg@chromium.org> wrote: > >> > >> Hi Ilias, > >> > >> On Wed, 14 Aug 2024 at 07:45, Ilias Apalodimas > >> <ilias.apalodimas@linaro.org> 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 present two enties for the > >> > >> entries > >> > >> > EFI_LOADER and EFI options in the main config screen. > >> > While at it add menus for Capsules, Protocols, and Services in the > >> > EFI_LOADER so people can find their way around easier > >> > > >> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> > >> > --- > >> > Kconfig | 4 + > >> > lib/Kconfig | 2 - > >> > lib/efi/Kconfig | 5 + > >> > lib/efi_loader/Kconfig | 202 > +++++++++++++++++++++++------------------ > >> > 4 files changed, 123 insertions(+), 90 deletions(-) > >> > > >> > diff --git a/Kconfig b/Kconfig > >> > index 82df59f176ec..62c5441e3576 100644 > >> > --- a/Kconfig > >> > +++ b/Kconfig > >> > @@ -756,3 +756,7 @@ source "lib/Kconfig" > >> > source "test/Kconfig" > >> > > >> > source "tools/Kconfig" > >> > + > >> > +source "lib/efi_loader/Kconfig" > >> > + > >> > >> This should be included from boot/Kconfig as it relates to booting. > > > > > > Hmm why? Booting is one of the things efi does. I prefer having it on > the main menu since it's a pointer to the entire spec, protocols, services > etc > > True. From a functionality point of view, there is booting and > firmware update. Is there anything else? I have thought for a while > that we should perhaps have an 'update' menu. Where, for example, > would VBE fit in the menus? > Why don't we do something similar for VBE? I agree that those are the 2 main categories, but I think it's far more intuitive to have all in one place depending on what to choose to boot and upgrade your device. Otherwise you have to enable the 'boot method' and start navigation around for updates etc. > > > > > >> > >> The EFI app thing should perhaps be under there too...I'm not sure. > > > > > > I was toying around with the idea as well. But eventually I decided this > needs it's own entry since it's about building U-Boot as a pe/coff. I don't > mind changing this though. > > Yes, building as an app isn't really about booting. It looks very > lonely at the end of the menu, though. > I'll fold this in to UEFI Cheers Ilias > > Regards, > Simon > > > > > Thanks > > Ilias > >> > >> > >> Regards, > >> Simon >
Hi Ilias, On Fri, 16 Aug 2024 at 19:49, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Simon > > On mobile apologies for any weird formatting in advance. > > On Fri, Aug 16, 2024, 04:34 Simon Glass <sjg@chromium.org> wrote: >> >> Hi Ilias, >> >> On Thu, 15 Aug 2024 at 15:11, Ilias Apalodimas >> <ilias.apalodimas@linaro.org> wrote: >> > >> > >> > >> > On Thu, Aug 15, 2024, 23:33 Simon Glass <sjg@chromium.org> wrote: >> >> >> >> Hi Ilias, >> >> >> >> On Wed, 14 Aug 2024 at 07:45, Ilias Apalodimas >> >> <ilias.apalodimas@linaro.org> 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 present two enties for the >> >> >> >> entries >> >> >> >> > EFI_LOADER and EFI options in the main config screen. >> >> > While at it add menus for Capsules, Protocols, and Services in the >> >> > EFI_LOADER so people can find their way around easier >> >> > >> >> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> >> >> > --- >> >> > Kconfig | 4 + >> >> > lib/Kconfig | 2 - >> >> > lib/efi/Kconfig | 5 + >> >> > lib/efi_loader/Kconfig | 202 +++++++++++++++++++++++------------------ >> >> > 4 files changed, 123 insertions(+), 90 deletions(-) >> >> > >> >> > diff --git a/Kconfig b/Kconfig >> >> > index 82df59f176ec..62c5441e3576 100644 >> >> > --- a/Kconfig >> >> > +++ b/Kconfig >> >> > @@ -756,3 +756,7 @@ source "lib/Kconfig" >> >> > source "test/Kconfig" >> >> > >> >> > source "tools/Kconfig" >> >> > + >> >> > +source "lib/efi_loader/Kconfig" >> >> > + >> >> >> >> This should be included from boot/Kconfig as it relates to booting. >> > >> > >> > Hmm why? Booting is one of the things efi does. I prefer having it on the main menu since it's a pointer to the entire spec, protocols, services etc >> >> True. From a functionality point of view, there is booting and >> firmware update. Is there anything else? I have thought for a while >> that we should perhaps have an 'update' menu. Where, for example, >> would VBE fit in the menus? > > > Why don't we do something similar for VBE? I agree that those are the 2 main categories, but I think it's far more intuitive to have all in one place depending on what to choose to boot and upgrade your device. > > Otherwise you have to enable the 'boot method' and start navigation around for updates etc. Hmm, for now (I think?) we have everything related to boot and update in boot/ - is that right? So I would favour having the 'EFI' thing in boot/Kconfig. It is a bit like BOOTSTD_DEFAULTS, where we enable the common things that people are likely to want. So when you turn on EFI_LOADER (which is generally on by default) you get the booting and updating features. Maybe the EFI_LOADER should be just for the loader and we should have something more generic (EFI_DEFAULTS ?) to enable the common things. We don't have an equivalent for VBE, but sometime before the end of Sept I will post the A/b/recovery method and it will be in better shape. > >> >> > >> > >> >> >> >> The EFI app thing should perhaps be under there too...I'm not sure. >> > >> > >> > I was toying around with the idea as well. But eventually I decided this needs it's own entry since it's about building U-Boot as a pe/coff. I don't mind changing this though. >> >> Yes, building as an app isn't really about booting. It looks very >> lonely at the end of the menu, though. > > > I'll fold this in to UEFI Seems reasonable to me. Oddly U-Boot doesn't fully support booting with UEFI when booted from UEFI...some sort of pass-through. So for now the EFI app and EFI loader are not really related. But we certainly don't want it at the top level. Regards, Simon
diff --git a/Kconfig b/Kconfig index 82df59f176ec..62c5441e3576 100644 --- a/Kconfig +++ b/Kconfig @@ -756,3 +756,7 @@ source "lib/Kconfig" source "test/Kconfig" source "tools/Kconfig" + +source "lib/efi_loader/Kconfig" + +source "lib/efi/Kconfig" 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 1179c31bb136..26838d20f2de 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,3 +1,5 @@ +menu "UEFI Loader" + 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,40 +401,6 @@ config EFI_UNICODE_CAPITALIZATION endif -config EFI_LOADER_BOUNCE_BUFFER - bool "EFI Applications use bounce buffers for DMA operations" - depends on ARM64 - 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 @@ -448,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 + 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_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_ESRT bool "Enable the UEFI ESRT generation" @@ -497,15 +509,26 @@ config EFI_EBBR_2_1_CONFORMANCE help Enabling this option adds the EBBRv2.1 conformance entry to the ECPT UEFI table. -config EFI_RISCV_BOOT_PROTOCOL - bool "RISCV_EFI_BOOT_PROTOCOL support" +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. + +endmenu + +menu "EFI bootmanager" + +config EFI_BOOTMGR + bool "UEFI Boot Manager" default y - depends on RISCV help - 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. + 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. config EFI_HTTP_BOOT bool "EFI HTTP Boot support" @@ -515,5 +538,8 @@ config EFI_HTTP_BOOT help Enabling this option adds EFI HTTP Boot support. It allows to directly boot from network. +endmenu endif + +endmenu
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 present two enties for the EFI_LOADER and EFI options in the main config screen. While at it add menus for Capsules, Protocols, and Services in the EFI_LOADER so people can find their way around easier Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> --- Kconfig | 4 + lib/Kconfig | 2 - lib/efi/Kconfig | 5 + lib/efi_loader/Kconfig | 202 +++++++++++++++++++++++------------------ 4 files changed, 123 insertions(+), 90 deletions(-)