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 everything
> > +	  on 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 an
> > +	  interface between platform firmware and an operating system that is
> > +	  suitable for embedded platforms. EBBR-compliant platforms present a
> > +	  consistent interface that will boot an EBBR-compliant operating
> > +	  system without any custom tailoring required. For example, an Arm
> > +	  A-class embedded platform will benefit from a standard interface that
> > +	  supports 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.

-- 
Tom