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

Thu May 9 16:05:57 UTC 2019

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.

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