From mboxrd@z Thu Jan  1 00:00:00 1970
From: Graf, Alexander <graf@amazon.com>
Date: Thu, 9 May 2019 00:15:34 +0200
Subject: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
In-Reply-To: <04c55d81-c835-aa90-053a-f47956e7fef0@gmx.de>
References: <302b84e3-4ac7-25ad-3eba-b624ad48eb23@gmx.de>
 <20190508175053.GR25571@bill-the-cat>
 <04c55d81-c835-aa90-053a-f47956e7fef0@gmx.de>
Message-ID: <6bc77f91-6a99-6f4f-cae9-b16d5a10b227@amazon.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
To: u-boot@lists.denx.de


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