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 <tr...@konsulko.com> > Date: Thu May 9 10:06:40 2019 -0400 > > LOCAL: Disable some EFI stuff by default > > Signed-off-by: Tom Rini <tr...@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. 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. My priority is on using the UEFI SCT to identify areas were our UEFI implementation is incorrect. Best regards Heinrich _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot