[U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)

Thu May 9 16:10:45 UTC 2019

On Thu, May 09, 2019 at 06:05:57PM +0200, Heinrich Schuchardt wrote:
> On 5/9/19 4:16 PM, Tom Rini wrote:
> > On Thu, May 09, 2019 at 12:03:38AM +0200, Heinrich Schuchardt wrote:
> >> On 5/8/19 7:50 PM, Tom Rini wrote:
> >>> On Wed, May 08, 2019 at 07:57:57AM +0200, Heinrich Schuchardt wrote:
> >>>
> >>>> The following changes since commit
> >>>> 44237e272f1eac3b026709e76333a07b2d3a3523:
> >>>>
> >>>> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-06
> >>>> 07:19:31 -0400)
> >>>>
> >>>> are available in the Git repository at:
> >>>>
> >>>> git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc2-2
> >>>>
> >>>> for you to fetch changes up to
> >>>> b015ab57bf558daa1c768995a7a7f1df2d40191e:
> >>>>
> >>>> efi_loader: signature of ExitBootServices() (2019-05-07 21:10:04
> >>>> +0200)
> >>>>
> >>>> Travis CI results are here:
> >>>> https://travis-ci.org/xypron2/u-boot/builds/529448555
> >>>>
> >>>> Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7  6D33 C481 DBBC
> >>>> 2C05 1AC4
> >>>>
> >>>
> >>> Note that you may want to run ./scripts/checkpatch.pl --git
> >>> origin/master.. or similar as: WARNING: 'follwing' may be misspelled
> >>> - perhaps 'following'?
> >>>
> >>> which I left alone rather than mess up the tag.
> >>
> >> Sorry I missed that one. Typically I run checkpatch.pl.
> >>
> >>>
> >>> Applied to u-boot/master, thanks!
> >>>
> >>> And all of that said, looking over my before/after builds I see a lot
> >>> of size growth, everywhere, due to EFI changes.  I assume this is due
> >>> to increasing overall functionality and support, which is good.  But
> >>> is there perhaps some way we can split things into a minimal "we
> >>> have enough to support loading ${OS LOADER}" and then "we are aiming
> >>> for large parts of spec compliance" ?  Some days I start to wonder
> >>> if "EFI_LOADER on by default" was a bad idea.
> >>>
> >>
> >> The following switches allow to reduce the size of the UEFI subsystem:
> >>
> >> CONFIG_CMD_BOOTEFI_HELLO, default N
> >> CONFIG_CMD_BOOTEFI_SELFTEST, default N except QEMU
> >
> > Note there's 2 non-QEMU platforms enabling it, can you please add a
> > patch turning it off and cc'ing the maintainer as they probably didn't
> > really mean to have that on?  It's also not on for riscv QEMU nor
> > sandbox but should be?
> >
> >> CONFIG_EFI_UNICODE_CAPITALIZATION, default Y
> >> CONFIG_EFI_LOADER_HII
> >> (The Makefile does not consider it yet correctly, patch submitted.)
> >> CONFIG_CMD_EFIDEBUG, default N
> >> CONFIG_CMD_NVEDIT_EFI
> >
> > Adding in:
> > commit 7494b7764508332e37a3375fa0b6c328bc34637f
> > Author: Tom Rini <trini at konsulko.com>
> > Date:   Thu May 9 10:06:40 2019 -0400
> >
> >     LOCAL: Disable some EFI stuff by default
> >
> >     Signed-off-by: Tom Rini <trini at konsulko.com>
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 4e11e0f404c8..4ebaf2f5bcb9 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -238,7 +238,6 @@ config CMD_BOOTEFI
> >  config CMD_BOOTEFI_HELLO_COMPILE
> >  	bool "Compile a standard EFI hello world binary for testing"
> >  	depends on CMD_BOOTEFI && !CPU_V7M && !SANDBOX
> > -	default y
> >  	help
> >  	  This compiles a standard EFI hello world application with U-Boot so
> >  	  that it can be used with the test/py testing framework. This is useful
> > @@ -434,7 +433,6 @@ config CMD_ENV_FLAGS
> >  config CMD_NVEDIT_EFI
> >  	bool "env [set|print] -e - set/print UEFI variables"
> >  	depends on EFI_LOADER
> > -	default y
> >  	imply HEXDUMP
> >  	help
> >  	  UEFI variables are encoded as some form of U-Boot variables.
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 50b050159c37..bd8fb9be00bc 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -19,7 +19,6 @@ config EFI_LOADER
> >  config EFI_UNICODE_CAPITALIZATION
> >  	bool "Support Unicode capitalization"
> >  	depends on EFI_LOADER
> > -	default y
> >  	help
> >  	  Select this option to enable correct handling of the capitalization of
> >  	  Unicode codepoints in the range 0x0000-0xffff. If this option is not
> > @@ -48,7 +47,6 @@ config EFI_LOADER_BOUNCE_BUFFER
> >  config EFI_LOADER_HII
> >  	bool "Expose HII protocols to EFI applications"
> >  	depends on EFI_LOADER
> > -	default y
> >  	help
> >  	  The Human Interface Infrastructure is a complicated framework that
> >  	  allows UEFI applications to draw fancy menus and hook strings using
> >
> > And note that with the bugfix to the Makefile for EFI_LOADER_HII added,
> > there's either more to be done, or it was already being discarded at
> > link time as applying that patch on top of this didn't result in any
> > size savings.  Doing the above saves about 10kb.  Which helps, but with
> > the numbers I mentioned earlier still puts us at about 40kb which Alex
> > was hoping it should be closer to 20kb.  Is there more we can do here?
> > Thanks!
> >
> 
> I already mentioned further areas that possibly can be made customizable
> in this thread.

OK, lets aim for those please.

> Alex numbers refer to a state where everything except starting GRUB
> would fail in the 1st half of 2017. Even the most simple conceivable
> UEFI binary doing nothing but `return EFI_SUCCESS;` resulted in a crash.

A good data-point too, yes.

> My priority is on using the UEFI SCT to identify areas were our UEFI
> implementation is incorrect.

We need to be correct, yes.  And we aim to be EBBR compliant (as that's
quite a large point of this feature).  But time and again other
maintainers note that our binary size keeps growing without visibly
useful features, either to them or to the end user.  So being able to
run SCT is helpful and good.  But being able to run grub2 or the BSD
loader or what-have-you is the end user visible feature.  And if there's
a big delta between that and what EBBR says we need to have, that's a
good point and place to push back on EBBR (where we're both invited to
the meetings and anyone else reading this and has concerns is too!).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190509/6863f44e/attachment.sig>