On Thu, Jul 29, 2021 at 02:12:19AM +0200, Heinrich Schuchardt wrote:
On 7/2/21 8:36 PM, Simon Glass wrote:
Add a new Kconfig option for EBBR so that the naming is more explicit. Make it select EFI_LOADER which is required for EBBR to work.
Copy over the same 'default' setting so that there is no change in which boards enable it.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2:
Split out new patch to create an option for EBBR
common/Kconfig.boot | 16 ++++++++++++++++ lib/efi_loader/Kconfig | 1 - 2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/common/Kconfig.boot b/common/Kconfig.boot index 89a3161f1fa..111032e1202 100644 --- a/common/Kconfig.boot +++ b/common/Kconfig.boot @@ -300,6 +300,22 @@ config LEGACY_IMAGE_FORMAT loaded. If a board needs the legacy image format support in this case, enable it here.
+config EBBR
- bool "Enable support for Embeeded Boot Base Requirements (EBBR)"
- select EFI_LOADER
- default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
This won't work. You cannot have UEFI neither on big-endian systems nor on any other architecture not mentioned in the UEFI specification.
Why do you want to exclude arm1136 and arm1176?
This is just moving the default y logic from EFI_LOADER over here.
- help
Enable this to support ARM's EBBR boot method. This bases everythingon UEFI protocols.´EBBR is explitely not ARM specific. EBBR is not a boot method but a subset of the UEFI specification.
This Embedded Base Boot Requirements (EBBR) specification defines aninterface between platform firmware and an operating system that issuitable for embedded platforms. EBBR-compliant platforms present aconsistent interface that will boot an EBBR-compliant operatingsystem without any custom tailoring required. For example, an ArmA-class embedded platform will benefit from a standard interface thatsupports features such as secure boot and firmware update.Which user will ever have heard of the EBBR specification? Referencing it in Kconfig will lead to confusion.
This new symbol is redundant. If you think that a better name for EFI_LOADER is needed, please suggest one.
At this point in time, yes, there's no need for a separate EBBR symbol as everything we need to be compliant comes down to "enable EFI_LOADER". It is possible that in the future we may need / want a specific symbol to ensure we have all of the required EBBR functionality as some of it may end up being non-default.