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

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

[Tom Rini]

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.

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/55327928/attachment.sig>

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

[Heinrich Schuchardt]

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.

Best regards

Heinrich

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

[Tom Rini]

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
> 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.

Right.  And I think we need to make the defaults reflect that, and then
have some targets opt-in for more (such as QEMU where we're testing
things).

> 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.

Adding more options to be able to remove stuff would be good, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190508/b9bcc6d1/attachment.sig>

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

[Graf, Alexander]

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] Pull request for UEFI sub-system for v2019.07-rc2 (2)

[Tom Rini]

On Thu, May 09, 2019 at 12:15:34AM +0200, Graf, Alexander wrote:
> 
> 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.

On am335x_evm disabling CONFIG_EFI_LOADER saves 51kb and on pine64-lts
disabling CONFIG_EFI_LOADER saves 75kb.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190509/c6293d9c/attachment.sig>

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

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190509/f3607188/attachment.sig>

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

[Heinrich Schuchardt]

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

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

[Tom Rini]

On Thu, May 09, 2019 at 06:05:57PM +0200, Heinrich Schuchardt wrote:
> 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.

OK, lets aim for those please.

> 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.

A good data-point too, yes.

> My priority is on using the UEFI SCT to identify areas were our UEFI
> implementation is incorrect.

We need to be correct, yes.  And we aim to be EBBR compliant (as that's
quite a large point of this feature).  But time and again other
maintainers note that our binary size keeps growing without visibly
useful features, either to them or to the end user.  So being able to
run SCT is helpful and good.  But being able to run grub2 or the BSD
loader or what-have-you is the end user visible feature.  And if there's
a big delta between that and what EBBR says we need to have, that's a
good point and place to push back on EBBR (where we're both invited to
the meetings and anyone else reading this and has concerns is too!).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190509/6863f44e/attachment.sig>