On 09.05.19 00:03, 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
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

In doc/README.uefi we describe that we target EBBR compatibility.

We have implemented functionality that is not needed for EBBR
compatibility but is needed to run the EFI Shell and the conformance
tests or iPXE. Here we should think about making it customizable, e.g.

lib/efi_loader/efi_bootmgr.c
lib/efi_driver/*
lib/efi_loader/efi_unicode_collation.c
lib/efi_loader/efi_variable.c
lib/efi_loader/device_path_to_text.c
lib/efi_loader/device_path_utilities.c

For the Unicode collation protocol I just sent a patch.


Do you have size estimates for how much each of those bits are? Where did we see the biggest growth? What eats up the most code/data space?

I think we should aim to ideally incur less than 20kb overhead for an arm target. How far are we from that? We used to be at 10kb.


Alex


_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to