[PATCH v2 8/9] Add an option for EBBR
Tom Rini
trini at konsulko.com
Thu Jul 29 02:40:10 CEST 2021
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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210728/33536f58/attachment.sig>
More information about the U-Boot
mailing list