From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
Date: Thu, 9 May 2019 18:05:57 +0200 [thread overview]
Message-ID: <cfb7c28d-286f-6970-82d6-87348a0fd940@gmx.de> (raw)
In-Reply-To: <20190509141605.GE25571@bill-the-cat>
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@konsulko.com>
> Date: Thu May 9 10:06:40 2019 -0400
>
> LOCAL: Disable some EFI stuff by default
>
> Signed-off-by: Tom Rini <trini@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
next prev parent reply other threads:[~2019-05-09 16:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <302b84e3-4ac7-25ad-3eba-b624ad48eb23@gmx.de>
2019-05-08 17:50 ` [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2) Tom Rini
2019-05-08 22:03 ` Heinrich Schuchardt
2019-05-08 22:06 ` Tom Rini
2019-05-08 22:15 ` Graf, Alexander
2019-05-09 11:27 ` Tom Rini
2019-05-09 14:16 ` Tom Rini
2019-05-09 16:05 ` Heinrich Schuchardt [this message]
2019-05-09 16:10 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cfb7c28d-286f-6970-82d6-87348a0fd940@gmx.de \
--to=xypron.glpk@gmx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox