Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
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
> > Date: Thu May 9 10:06:40 2019 -0400
> >
> > LOCAL: Disable some EFI stuff by default
> >
> > Signed-off-by: Tom Rini
> >
> > 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 0x-0x. 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
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
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
> Date: Thu May 9 10:06:40 2019 -0400
>
> LOCAL: Disable some EFI stuff by default
>
> Signed-off-by: Tom Rini
>
> 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 0x-0x. 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
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
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
Date: Thu May 9 10:06:40 2019 -0400
LOCAL: Disable some EFI stuff by default
Signed-off-by: Tom Rini
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 0x-0x. 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
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
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
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
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
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
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 mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
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
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
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
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
