Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
On Mon, Mar 28, 2022 at 12:35:09AM -0600, Simon Glass wrote: > Hi Tom, > > On Fri, 30 Jul 2021 at 16:08, Tom Rini wrote: > > > > On Fri, Jul 30, 2021 at 03:48:15PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 30 Jul 2021 at 15:33, Tom Rini wrote: > > > > > > > > On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 29 Jul 2021 at 07:52, Tom Rini wrote: > > > > > > > > > > > > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote: > > > > > > > > > > > > > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote: > > > > > > > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > > > > > > > > > > > > > > > > > > > > > This feature should never have been made available when > > > > > > > > > > > driver model > > > > > > > > > > > or devicetree are disabled. Add these as conditions, so > > > > > > > > > > > that we don't > > > > > > > > > > > create even more barriers to migration. > > > > > > > > > > > > > > > > > > > > > > Add a note about the substantial size increment > > > > > > > > > > > associated with this > > > > > > > > > > > option. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > - Split out new patch to make EFI_LOADER depend on DM and > > > > > > > > > > > OF_CONTROL > > > > > > > > > > > - Note the approximate size of this feature in the help > > > > > > > > > > > > > > > > > > > > > > lib/efi_loader/Kconfig | 4 +++- > > > > > > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig > > > > > > > > > > > b/lib/efi_loader/Kconfig > > > > > > > > > > > index 6242caceb7f..466abfed300 100644 > > > > > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > > > > > @@ -1,6 +1,6 @@ > > > > > > > > > > > config EFI_LOADER > > > > > > > > > > > bool "Support running UEFI applications" > > > > > > > > > > > - depends on OF_LIBFDT && ( \ > > > > > > > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > > > > > > > > > > > > > > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't > > > > > > > > > we get rid > > > > > > > > > of this symbol? > > > > > > > > > > > > > > > > No, but I did send out a message about that today as we're very > > > > > > > > close. > > > > > > > > Much closer than I had expected us to be. > > > > > > > > > > > > > > Note we will still have SPL_DM, I think. > > > > > > > > > > > > Right. > > > > > > > > > > > > > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL > > > > > > > > > and not DM? > > > > > > > > > > > > > > > > Yes, a few. It's vexpress_aemv8a_semi, warp (fixed by > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/ > > > > > > > > so false positive), cm_t335, devkit8000, armadillo-800eva, > > > > > > > > kzm9g and sniper. > > > > > > > > > > > > > > > > > Why are these separate symbols? Isn't this symbol to be > > > > > > > > > eliminated, too? > > > > > > > > > > > > > > > > Simon? > > > > > > > > > > > > > > If we do eliminate DM it will be in a separate series. Like Tom I > > > > > > > am > > > > > > > pleasantly surprised at how close we are. > > > > > > > > > > > > > > But please let's consider patches on their merits. It is fine to > > > > > > > reply > > > > > > > with a wishlist but even better to reply with a follow-up patch. > > > > > > > > > > > > OK. So, build-wise, EFI_LOADER does not require OF_CONTROL. > > > > > > > > > > I strongly believe it should (and it should have 5 years ago too). New > > > > > features should not be built on pre-migration stuff. > > > > > > > > Well, what legacy interfaces is it using? That's something to figure > > > > out and address as needed. > > > > > > It was built on non-DM and I believe it still has code for non-DM > > > (e.g. look for DM_MMC). Without DM, OF_CONTROL has no purpose IMO. > > > > > > Perhaps Heinrich has cleaned a lot of that old cruft out now? > > > > Now that DM_MMC and DM_VIDEO are mandatory, there is some cruft that can > > be removed, both there and probably tree-wide. But that's not the same > > as OF_CONTROL. Not all DM_xxx requires OF_CONTROL support. > > > > > > > > > Somewhat related, I think we need to create a separate symbol > > > > > > > which > > > > > > > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing. > > > > > > > > > > > > > > Also I think we should push of-platdata, since otherwise we're > > > > > > > going > > > > > > > to hit the same problem of migrating SPL boards to DM
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
Hi Tom, On Fri, 30 Jul 2021 at 16:08, Tom Rini wrote: > > On Fri, Jul 30, 2021 at 03:48:15PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 30 Jul 2021 at 15:33, Tom Rini wrote: > > > > > > On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 29 Jul 2021 at 07:52, Tom Rini wrote: > > > > > > > > > > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote: > > > > > > Hi, > > > > > > > > > > > > On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote: > > > > > > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > > > > > > > > > > > > > > > > > > > This feature should never have been made available when > > > > > > > > > > driver model > > > > > > > > > > or devicetree are disabled. Add these as conditions, so > > > > > > > > > > that we don't > > > > > > > > > > create even more barriers to migration. > > > > > > > > > > > > > > > > > > > > Add a note about the substantial size increment associated > > > > > > > > > > with this > > > > > > > > > > option. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > - Split out new patch to make EFI_LOADER depend on DM and > > > > > > > > > > OF_CONTROL > > > > > > > > > > - Note the approximate size of this feature in the help > > > > > > > > > > > > > > > > > > > > lib/efi_loader/Kconfig | 4 +++- > > > > > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > > > > > index 6242caceb7f..466abfed300 100644 > > > > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > > > > @@ -1,6 +1,6 @@ > > > > > > > > > > config EFI_LOADER > > > > > > > > > > bool "Support running UEFI applications" > > > > > > > > > > - depends on OF_LIBFDT && ( \ > > > > > > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > > > > > > > > > > > > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we > > > > > > > > get rid > > > > > > > > of this symbol? > > > > > > > > > > > > > > No, but I did send out a message about that today as we're very > > > > > > > close. > > > > > > > Much closer than I had expected us to be. > > > > > > > > > > > > Note we will still have SPL_DM, I think. > > > > > > > > > > Right. > > > > > > > > > > > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and > > > > > > > > not DM? > > > > > > > > > > > > > > Yes, a few. It's vexpress_aemv8a_semi, warp (fixed by > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/ > > > > > > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g > > > > > > > and sniper. > > > > > > > > > > > > > > > Why are these separate symbols? Isn't this symbol to be > > > > > > > > eliminated, too? > > > > > > > > > > > > > > Simon? > > > > > > > > > > > > If we do eliminate DM it will be in a separate series. Like Tom I am > > > > > > pleasantly surprised at how close we are. > > > > > > > > > > > > But please let's consider patches on their merits. It is fine to > > > > > > reply > > > > > > with a wishlist but even better to reply with a follow-up patch. > > > > > > > > > > OK. So, build-wise, EFI_LOADER does not require OF_CONTROL. > > > > > > > > I strongly believe it should (and it should have 5 years ago too). New > > > > features should not be built on pre-migration stuff. > > > > > > Well, what legacy interfaces is it using? That's something to figure > > > out and address as needed. > > > > It was built on non-DM and I believe it still has code for non-DM > > (e.g. look for DM_MMC). Without DM, OF_CONTROL has no purpose IMO. > > > > Perhaps Heinrich has cleaned a lot of that old cruft out now? > > Now that DM_MMC and DM_VIDEO are mandatory, there is some cruft that can > be removed, both there and probably tree-wide. But that's not the same > as OF_CONTROL. Not all DM_xxx requires OF_CONTROL support. > > > > > > > Somewhat related, I think we need to create a separate symbol which > > > > > > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing. > > > > > > > > > > > > Also I think we should push of-platdata, since otherwise we're going > > > > > > to hit the same problem of migrating SPL boards to DM one day. > > > > > > > > > > Note that we don't have CONFIG_OF_PLATDATA just > > > > > CONFIG_(SPL|TPL)_OF_PLATDATA. > > > > > > > > Indeed. But we haven't defined it because we don't want to permit it. > > > > It is just for constrained environments and we assume that U-Boot > > > > proper has enough space (how else could it load Linux?) > > > > >
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
On Fri, Jul 30, 2021 at 03:48:15PM -0600, Simon Glass wrote: > Hi Tom, > > On Fri, 30 Jul 2021 at 15:33, Tom Rini wrote: > > > > On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 29 Jul 2021 at 07:52, Tom Rini wrote: > > > > > > > > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote: > > > > > Hi, > > > > > > > > > > On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote: > > > > > > > > > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote: > > > > > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > > > > > > > > > > > > > > > > > This feature should never have been made available when > > > > > > > > > driver model > > > > > > > > > or devicetree are disabled. Add these as conditions, so that > > > > > > > > > we don't > > > > > > > > > create even more barriers to migration. > > > > > > > > > > > > > > > > > > Add a note about the substantial size increment associated > > > > > > > > > with this > > > > > > > > > option. > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > --- > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > - Split out new patch to make EFI_LOADER depend on DM and > > > > > > > > > OF_CONTROL > > > > > > > > > - Note the approximate size of this feature in the help > > > > > > > > > > > > > > > > > > lib/efi_loader/Kconfig | 4 +++- > > > > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > > > > index 6242caceb7f..466abfed300 100644 > > > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > > > @@ -1,6 +1,6 @@ > > > > > > > > > config EFI_LOADER > > > > > > > > > bool "Support running UEFI applications" > > > > > > > > > - depends on OF_LIBFDT && ( \ > > > > > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > > > > > > > > > > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we > > > > > > > get rid > > > > > > > of this symbol? > > > > > > > > > > > > No, but I did send out a message about that today as we're very > > > > > > close. > > > > > > Much closer than I had expected us to be. > > > > > > > > > > Note we will still have SPL_DM, I think. > > > > > > > > Right. > > > > > > > > > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and > > > > > > > not DM? > > > > > > > > > > > > Yes, a few. It's vexpress_aemv8a_semi, warp (fixed by > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/ > > > > > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g > > > > > > and sniper. > > > > > > > > > > > > > Why are these separate symbols? Isn't this symbol to be > > > > > > > eliminated, too? > > > > > > > > > > > > Simon? > > > > > > > > > > If we do eliminate DM it will be in a separate series. Like Tom I am > > > > > pleasantly surprised at how close we are. > > > > > > > > > > But please let's consider patches on their merits. It is fine to reply > > > > > with a wishlist but even better to reply with a follow-up patch. > > > > > > > > OK. So, build-wise, EFI_LOADER does not require OF_CONTROL. > > > > > > I strongly believe it should (and it should have 5 years ago too). New > > > features should not be built on pre-migration stuff. > > > > Well, what legacy interfaces is it using? That's something to figure > > out and address as needed. > > It was built on non-DM and I believe it still has code for non-DM > (e.g. look for DM_MMC). Without DM, OF_CONTROL has no purpose IMO. > > Perhaps Heinrich has cleaned a lot of that old cruft out now? Now that DM_MMC and DM_VIDEO are mandatory, there is some cruft that can be removed, both there and probably tree-wide. But that's not the same as OF_CONTROL. Not all DM_xxx requires OF_CONTROL support. > > > > > Somewhat related, I think we need to create a separate symbol which > > > > > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing. > > > > > > > > > > Also I think we should push of-platdata, since otherwise we're going > > > > > to hit the same problem of migrating SPL boards to DM one day. > > > > > > > > Note that we don't have CONFIG_OF_PLATDATA just > > > > CONFIG_(SPL|TPL)_OF_PLATDATA. > > > > > > Indeed. But we haven't defined it because we don't want to permit it. > > > It is just for constrained environments and we assume that U-Boot > > > proper has enough space (how else could it load Linux?) > > > > If OF_PLATDATA for U-Boot itself makes sense or not is a separate > > discussion to have. > > OK, I'd love to hear the reasoning on that one day. This might come up again real soon now in the context of nokia_rx51 and migrating away from the very old MUSB gadget driver and to modern DM_USB_GADGET. The p
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
Hi Tom, On Fri, 30 Jul 2021 at 15:33, Tom Rini wrote: > > On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 29 Jul 2021 at 07:52, Tom Rini wrote: > > > > > > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote: > > > > Hi, > > > > > > > > On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote: > > > > > > > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote: > > > > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > > > > > > > > > > > > > > > This feature should never have been made available when driver > > > > > > > > model > > > > > > > > or devicetree are disabled. Add these as conditions, so that we > > > > > > > > don't > > > > > > > > create even more barriers to migration. > > > > > > > > > > > > > > > > Add a note about the substantial size increment associated with > > > > > > > > this > > > > > > > > option. > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > --- > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > - Split out new patch to make EFI_LOADER depend on DM and > > > > > > > > OF_CONTROL > > > > > > > > - Note the approximate size of this feature in the help > > > > > > > > > > > > > > > > lib/efi_loader/Kconfig | 4 +++- > > > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > > > index 6242caceb7f..466abfed300 100644 > > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > > @@ -1,6 +1,6 @@ > > > > > > > > config EFI_LOADER > > > > > > > > bool "Support running UEFI applications" > > > > > > > > - depends on OF_LIBFDT && ( \ > > > > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > > > > > > > > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get > > > > > > rid > > > > > > of this symbol? > > > > > > > > > > No, but I did send out a message about that today as we're very close. > > > > > Much closer than I had expected us to be. > > > > > > > > Note we will still have SPL_DM, I think. > > > > > > Right. > > > > > > > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not > > > > > > DM? > > > > > > > > > > Yes, a few. It's vexpress_aemv8a_semi, warp (fixed by > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/ > > > > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and > > > > > sniper. > > > > > > > > > > > Why are these separate symbols? Isn't this symbol to be eliminated, > > > > > > too? > > > > > > > > > > Simon? > > > > > > > > If we do eliminate DM it will be in a separate series. Like Tom I am > > > > pleasantly surprised at how close we are. > > > > > > > > But please let's consider patches on their merits. It is fine to reply > > > > with a wishlist but even better to reply with a follow-up patch. > > > > > > OK. So, build-wise, EFI_LOADER does not require OF_CONTROL. > > > > I strongly believe it should (and it should have 5 years ago too). New > > features should not be built on pre-migration stuff. > > Well, what legacy interfaces is it using? That's something to figure > out and address as needed. It was built on non-DM and I believe it still has code for non-DM (e.g. look for DM_MMC). Without DM, OF_CONTROL has no purpose IMO. Perhaps Heinrich has cleaned a lot of that old cruft out now? > > > > > Somewhat related, I think we need to create a separate symbol which > > > > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing. > > > > > > > > Also I think we should push of-platdata, since otherwise we're going > > > > to hit the same problem of migrating SPL boards to DM one day. > > > > > > Note that we don't have CONFIG_OF_PLATDATA just > > > CONFIG_(SPL|TPL)_OF_PLATDATA. > > > > Indeed. But we haven't defined it because we don't want to permit it. > > It is just for constrained environments and we assume that U-Boot > > proper has enough space (how else could it load Linux?) > > If OF_PLATDATA for U-Boot itself makes sense or not is a separate > discussion to have. OK, I'd love to hear the reasoning on that one day. > > > > > > > lib/efi_loader/efi_disk.c is the only place where we maintain > > > > > > duplicate > > > > > > code for DM and non-DM. A dependency on CONFIG_BLK (which itself > > > > > > depends > > > > > > on CONFIG_DM) would make more sense to me. But only in a patch > > > > > > eliminating the non-BLK code. > > > > > > > > > > I just know that off-hand, partition + disk + block has some corner > > > > > case, but maybe that corner case is unintentional in terms of usage > > > > > today. > > > > > > > > > > > > > ARM && (SYS_CPU = arm1136 || \ > > > > > > > > SYS_CPU = arm1176 || \ > > > > > > > >
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 29 Jul 2021 at 07:52, Tom Rini wrote: > > > > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote: > > > Hi, > > > > > > On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote: > > > > > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote: > > > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > > > > > > > > > > > > > This feature should never have been made available when driver > > > > > > > model > > > > > > > or devicetree are disabled. Add these as conditions, so that we > > > > > > > don't > > > > > > > create even more barriers to migration. > > > > > > > > > > > > > > Add a note about the substantial size increment associated with > > > > > > > this > > > > > > > option. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > --- > > > > > > > > > > > > > > Changes in v2: > > > > > > > - Split out new patch to make EFI_LOADER depend on DM and > > > > > > > OF_CONTROL > > > > > > > - Note the approximate size of this feature in the help > > > > > > > > > > > > > > lib/efi_loader/Kconfig | 4 +++- > > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > > index 6242caceb7f..466abfed300 100644 > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > @@ -1,6 +1,6 @@ > > > > > > > config EFI_LOADER > > > > > > > bool "Support running UEFI applications" > > > > > > > - depends on OF_LIBFDT && ( \ > > > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > > > > > > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get > > > > > rid > > > > > of this symbol? > > > > > > > > No, but I did send out a message about that today as we're very close. > > > > Much closer than I had expected us to be. > > > > > > Note we will still have SPL_DM, I think. > > > > Right. > > > > > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM? > > > > > > > > Yes, a few. It's vexpress_aemv8a_semi, warp (fixed by > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/ > > > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and > > > > sniper. > > > > > > > > > Why are these separate symbols? Isn't this symbol to be eliminated, > > > > > too? > > > > > > > > Simon? > > > > > > If we do eliminate DM it will be in a separate series. Like Tom I am > > > pleasantly surprised at how close we are. > > > > > > But please let's consider patches on their merits. It is fine to reply > > > with a wishlist but even better to reply with a follow-up patch. > > > > OK. So, build-wise, EFI_LOADER does not require OF_CONTROL. > > I strongly believe it should (and it should have 5 years ago too). New > features should not be built on pre-migration stuff. Well, what legacy interfaces is it using? That's something to figure out and address as needed. > > > Somewhat related, I think we need to create a separate symbol which > > > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing. > > > > > > Also I think we should push of-platdata, since otherwise we're going > > > to hit the same problem of migrating SPL boards to DM one day. > > > > Note that we don't have CONFIG_OF_PLATDATA just > > CONFIG_(SPL|TPL)_OF_PLATDATA. > > Indeed. But we haven't defined it because we don't want to permit it. > It is just for constrained environments and we assume that U-Boot > proper has enough space (how else could it load Linux?) If OF_PLATDATA for U-Boot itself makes sense or not is a separate discussion to have. > > > > > lib/efi_loader/efi_disk.c is the only place where we maintain > > > > > duplicate > > > > > code for DM and non-DM. A dependency on CONFIG_BLK (which itself > > > > > depends > > > > > on CONFIG_DM) would make more sense to me. But only in a patch > > > > > eliminating the non-BLK code. > > > > > > > > I just know that off-hand, partition + disk + block has some corner > > > > case, but maybe that corner case is unintentional in terms of usage > > > > today. > > > > > > > > > > > ARM && (SYS_CPU = arm1136 || \ > > > > > > > SYS_CPU = arm1176 || \ > > > > > > > SYS_CPU = armv7 || \ > > > > > > > @@ -25,6 +25,8 @@ config EFI_LOADER > > > > > > > will expose the UEFI API to a loaded application, > > > > > > > enabling it to > > > > > > > reuse U-Boot's device drivers. > > > > > > > > > > > > > > + For ARM 32-bit, this adds about 90KB to the size of U-Boot. > > > > > > > + > > > > > > > > > > There is no unit ISO prefix K. Do you mean KiB? > > > > > > > > > > 90 KiB may be the value today. Will you update it regularly? Otherwise > > > > > don't pu
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
Hi Tom, On Thu, 29 Jul 2021 at 07:52, Tom Rini wrote: > > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote: > > Hi, > > > > On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote: > > > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote: > > > > > > > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote: > > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > > > > > > > > > > > This feature should never have been made available when driver model > > > > > > or devicetree are disabled. Add these as conditions, so that we > > > > > > don't > > > > > > create even more barriers to migration. > > > > > > > > > > > > Add a note about the substantial size increment associated with this > > > > > > option. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > --- > > > > > > > > > > > > Changes in v2: > > > > > > - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL > > > > > > - Note the approximate size of this feature in the help > > > > > > > > > > > > lib/efi_loader/Kconfig | 4 +++- > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > index 6242caceb7f..466abfed300 100644 > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > @@ -1,6 +1,6 @@ > > > > > > config EFI_LOADER > > > > > > bool "Support running UEFI applications" > > > > > > - depends on OF_LIBFDT && ( \ > > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > > > > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get rid > > > > of this symbol? > > > > > > No, but I did send out a message about that today as we're very close. > > > Much closer than I had expected us to be. > > > > Note we will still have SPL_DM, I think. > > Right. > > > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM? > > > > > > Yes, a few. It's vexpress_aemv8a_semi, warp (fixed by > > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/ > > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and > > > sniper. > > > > > > > Why are these separate symbols? Isn't this symbol to be eliminated, too? > > > > > > Simon? > > > > If we do eliminate DM it will be in a separate series. Like Tom I am > > pleasantly surprised at how close we are. > > > > But please let's consider patches on their merits. It is fine to reply > > with a wishlist but even better to reply with a follow-up patch. > > OK. So, build-wise, EFI_LOADER does not require OF_CONTROL. I strongly believe it should (and it should have 5 years ago too). New features should not be built on pre-migration stuff. > > > Somewhat related, I think we need to create a separate symbol which > > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing. > > > > Also I think we should push of-platdata, since otherwise we're going > > to hit the same problem of migrating SPL boards to DM one day. > > Note that we don't have CONFIG_OF_PLATDATA just > CONFIG_(SPL|TPL)_OF_PLATDATA. Indeed. But we haven't defined it because we don't want to permit it. It is just for constrained environments and we assume that U-Boot proper has enough space (how else could it load Linux?) > > > > > lib/efi_loader/efi_disk.c is the only place where we maintain duplicate > > > > code for DM and non-DM. A dependency on CONFIG_BLK (which itself depends > > > > on CONFIG_DM) would make more sense to me. But only in a patch > > > > eliminating the non-BLK code. > > > > > > I just know that off-hand, partition + disk + block has some corner > > > case, but maybe that corner case is unintentional in terms of usage > > > today. > > > > > > > > > ARM && (SYS_CPU = arm1136 || \ > > > > > > SYS_CPU = arm1176 || \ > > > > > > SYS_CPU = armv7 || \ > > > > > > @@ -25,6 +25,8 @@ config EFI_LOADER > > > > > > will expose the UEFI API to a loaded application, > > > > > > enabling it to > > > > > > reuse U-Boot's device drivers. > > > > > > > > > > > > + For ARM 32-bit, this adds about 90KB to the size of U-Boot. > > > > > > + > > > > > > > > There is no unit ISO prefix K. Do you mean KiB? > > > > > > > > 90 KiB may be the value today. Will you update it regularly? Otherwise > > > > don't put a number here. > > > > > > > > I can't see that the effect on size is truly architecture specific. Why > > > > do you refer to 32bit ARM? > > > > > > > > Such a comment would better fit into a documentation chapter on > > > > downsizing U-Boot. > > > > > > Yes, we should probably drop that specific note. > > > > From my POV I really like these notes in Kconfig. They appear in a few > > places and provide people with rough guidance. I'd like to see more of > > them. I don't know how we can keep them up-to-date, although I'd argue > > that they s
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote: > Hi, > > On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote: > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote: > > > > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote: > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > > > > > > > > > This feature should never have been made available when driver model > > > > > or devicetree are disabled. Add these as conditions, so that we don't > > > > > create even more barriers to migration. > > > > > > > > > > Add a note about the substantial size increment associated with this > > > > > option. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > --- > > > > > > > > > > Changes in v2: > > > > > - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL > > > > > - Note the approximate size of this feature in the help > > > > > > > > > > lib/efi_loader/Kconfig | 4 +++- > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > index 6242caceb7f..466abfed300 100644 > > > > > --- a/lib/efi_loader/Kconfig > > > > > +++ b/lib/efi_loader/Kconfig > > > > > @@ -1,6 +1,6 @@ > > > > > config EFI_LOADER > > > > > bool "Support running UEFI applications" > > > > > - depends on OF_LIBFDT && ( \ > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get rid > > > of this symbol? > > > > No, but I did send out a message about that today as we're very close. > > Much closer than I had expected us to be. > > Note we will still have SPL_DM, I think. Right. > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM? > > > > Yes, a few. It's vexpress_aemv8a_semi, warp (fixed by > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/ > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and sniper. > > > > > Why are these separate symbols? Isn't this symbol to be eliminated, too? > > > > Simon? > > If we do eliminate DM it will be in a separate series. Like Tom I am > pleasantly surprised at how close we are. > > But please let's consider patches on their merits. It is fine to reply > with a wishlist but even better to reply with a follow-up patch. OK. So, build-wise, EFI_LOADER does not require OF_CONTROL. > Somewhat related, I think we need to create a separate symbol which > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing. > > Also I think we should push of-platdata, since otherwise we're going > to hit the same problem of migrating SPL boards to DM one day. Note that we don't have CONFIG_OF_PLATDATA just CONFIG_(SPL|TPL)_OF_PLATDATA. > > > lib/efi_loader/efi_disk.c is the only place where we maintain duplicate > > > code for DM and non-DM. A dependency on CONFIG_BLK (which itself depends > > > on CONFIG_DM) would make more sense to me. But only in a patch > > > eliminating the non-BLK code. > > > > I just know that off-hand, partition + disk + block has some corner > > case, but maybe that corner case is unintentional in terms of usage > > today. > > > > > > > ARM && (SYS_CPU = arm1136 || \ > > > > > SYS_CPU = arm1176 || \ > > > > > SYS_CPU = armv7 || \ > > > > > @@ -25,6 +25,8 @@ config EFI_LOADER > > > > > will expose the UEFI API to a loaded application, > > > > > enabling it to > > > > > reuse U-Boot's device drivers. > > > > > > > > > > + For ARM 32-bit, this adds about 90KB to the size of U-Boot. > > > > > + > > > > > > There is no unit ISO prefix K. Do you mean KiB? > > > > > > 90 KiB may be the value today. Will you update it regularly? Otherwise > > > don't put a number here. > > > > > > I can't see that the effect on size is truly architecture specific. Why > > > do you refer to 32bit ARM? > > > > > > Such a comment would better fit into a documentation chapter on > > > downsizing U-Boot. > > > > Yes, we should probably drop that specific note. > > From my POV I really like these notes in Kconfig. They appear in a few > places and provide people with rough guidance. I'd like to see more of > them. I don't know how we can keep them up-to-date, although I'd argue > that they should stay constant, if we are holding to our no-bloat > ideal. I feel like EFI gets a bit of an undeserved reputation here. It's not growing any worse than the rest of the world is over fixes and error correction (which is to say, 16/32/40 bytes here and there). And there's not "big" new default features coming in. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
Hi, On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote: > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote: > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote: > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > > > > > > > This feature should never have been made available when driver model > > > > or devicetree are disabled. Add these as conditions, so that we don't > > > > create even more barriers to migration. > > > > > > > > Add a note about the substantial size increment associated with this > > > > option. > > > > > > > > Signed-off-by: Simon Glass > > > > --- > > > > > > > > Changes in v2: > > > > - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL > > > > - Note the approximate size of this feature in the help > > > > > > > > lib/efi_loader/Kconfig | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > index 6242caceb7f..466abfed300 100644 > > > > --- a/lib/efi_loader/Kconfig > > > > +++ b/lib/efi_loader/Kconfig > > > > @@ -1,6 +1,6 @@ > > > > config EFI_LOADER > > > > bool "Support running UEFI applications" > > > > - depends on OF_LIBFDT && ( \ > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get rid > > of this symbol? > > No, but I did send out a message about that today as we're very close. > Much closer than I had expected us to be. Note we will still have SPL_DM, I think. > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM? > > Yes, a few. It's vexpress_aemv8a_semi, warp (fixed by > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/ > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and sniper. > > > Why are these separate symbols? Isn't this symbol to be eliminated, too? > > Simon? If we do eliminate DM it will be in a separate series. Like Tom I am pleasantly surprised at how close we are. But please let's consider patches on their merits. It is fine to reply with a wishlist but even better to reply with a follow-up patch. Somewhat related, I think we need to create a separate symbol which means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing. Also I think we should push of-platdata, since otherwise we're going to hit the same problem of migrating SPL boards to DM one day. > > > lib/efi_loader/efi_disk.c is the only place where we maintain duplicate > > code for DM and non-DM. A dependency on CONFIG_BLK (which itself depends > > on CONFIG_DM) would make more sense to me. But only in a patch > > eliminating the non-BLK code. > > I just know that off-hand, partition + disk + block has some corner > case, but maybe that corner case is unintentional in terms of usage > today. > > > > > ARM && (SYS_CPU = arm1136 || \ > > > > SYS_CPU = arm1176 || \ > > > > SYS_CPU = armv7 || \ > > > > @@ -25,6 +25,8 @@ config EFI_LOADER > > > > will expose the UEFI API to a loaded application, enabling > > > > it to > > > > reuse U-Boot's device drivers. > > > > > > > > + For ARM 32-bit, this adds about 90KB to the size of U-Boot. > > > > + > > > > There is no unit ISO prefix K. Do you mean KiB? > > > > 90 KiB may be the value today. Will you update it regularly? Otherwise > > don't put a number here. > > > > I can't see that the effect on size is truly architecture specific. Why > > do you refer to 32bit ARM? > > > > Such a comment would better fit into a documentation chapter on > > downsizing U-Boot. > > Yes, we should probably drop that specific note. >From my POV I really like these notes in Kconfig. They appear in a few places and provide people with rough guidance. I'd like to see more of them. I don't know how we can keep them up-to-date, although I'd argue that they should stay constant, if we are holding to our no-bloat ideal. Perhaps the problem here is that EFI_LOADER is quite monolithic and still under development, so the size is TBD. On that basic I'm fine to drop it. Regards, Simon
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote: > > > On 7/27/21 12:07 AM, Tom Rini wrote: > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > > > > > This feature should never have been made available when driver model > > > or devicetree are disabled. Add these as conditions, so that we don't > > > create even more barriers to migration. > > > > > > Add a note about the substantial size increment associated with this > > > option. > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > Changes in v2: > > > - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL > > > - Note the approximate size of this feature in the help > > > > > > lib/efi_loader/Kconfig | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > index 6242caceb7f..466abfed300 100644 > > > --- a/lib/efi_loader/Kconfig > > > +++ b/lib/efi_loader/Kconfig > > > @@ -1,6 +1,6 @@ > > > config EFI_LOADER > > > bool "Support running UEFI applications" > > > - depends on OF_LIBFDT && ( \ > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get rid > of this symbol? No, but I did send out a message about that today as we're very close. Much closer than I had expected us to be. > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM? Yes, a few. It's vexpress_aemv8a_semi, warp (fixed by https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/ so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and sniper. > Why are these separate symbols? Isn't this symbol to be eliminated, too? Simon? > lib/efi_loader/efi_disk.c is the only place where we maintain duplicate > code for DM and non-DM. A dependency on CONFIG_BLK (which itself depends > on CONFIG_DM) would make more sense to me. But only in a patch > eliminating the non-BLK code. I just know that off-hand, partition + disk + block has some corner case, but maybe that corner case is unintentional in terms of usage today. > > > ARM && (SYS_CPU = arm1136 || \ > > > SYS_CPU = arm1176 || \ > > > SYS_CPU = armv7 || \ > > > @@ -25,6 +25,8 @@ config EFI_LOADER > > > will expose the UEFI API to a loaded application, enabling it > > > to > > > reuse U-Boot's device drivers. > > > > > > + For ARM 32-bit, this adds about 90KB to the size of U-Boot. > > > + > > There is no unit ISO prefix K. Do you mean KiB? > > 90 KiB may be the value today. Will you update it regularly? Otherwise > don't put a number here. > > I can't see that the effect on size is truly architecture specific. Why > do you refer to 32bit ARM? > > Such a comment would better fit into a documentation chapter on > downsizing U-Boot. Yes, we should probably drop that specific note. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
On 7/27/21 12:07 AM, Tom Rini wrote: On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: This feature should never have been made available when driver model or devicetree are disabled. Add these as conditions, so that we don't create even more barriers to migration. Add a note about the substantial size increment associated with this option. Signed-off-by: Simon Glass --- Changes in v2: - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL - Note the approximate size of this feature in the help lib/efi_loader/Kconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 6242caceb7f..466abfed300 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running UEFI applications" - depends on OF_LIBFDT && ( \ + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get rid of this symbol? Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM? Why are these separate symbols? Isn't this symbol to be eliminated, too? lib/efi_loader/efi_disk.c is the only place where we maintain duplicate code for DM and non-DM. A dependency on CONFIG_BLK (which itself depends on CONFIG_DM) would make more sense to me. But only in a patch eliminating the non-BLK code. ARM && (SYS_CPU = arm1136 || \ SYS_CPU = arm1176 || \ SYS_CPU = armv7 || \ @@ -25,6 +25,8 @@ config EFI_LOADER will expose the UEFI API to a loaded application, enabling it to reuse U-Boot's device drivers. + For ARM 32-bit, this adds about 90KB to the size of U-Boot. + There is no unit ISO prefix K. Do you mean KiB? 90 KiB may be the value today. Will you update it regularly? Otherwise don't put a number here. I can't see that the effect on size is truly architecture specific. Why do you refer to 32bit ARM? Such a comment would better fit into a documentation chapter on downsizing U-Boot. Best regards Heinrich if EFI_LOADER config CMD_BOOTEFI_BOOTMGR Note that we have platforms today with EFI_LOADER without OF_CONTROL, so this isn't strictly the right requirements. What do you think here Heinrich?
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > This feature should never have been made available when driver model > or devicetree are disabled. Add these as conditions, so that we don't > create even more barriers to migration. > > Add a note about the substantial size increment associated with this > option. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL > - Note the approximate size of this feature in the help > > lib/efi_loader/Kconfig | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index 6242caceb7f..466abfed300 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig > @@ -1,6 +1,6 @@ > config EFI_LOADER > bool "Support running UEFI applications" > - depends on OF_LIBFDT && ( \ > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > ARM && (SYS_CPU = arm1136 || \ > SYS_CPU = arm1176 || \ > SYS_CPU = armv7 || \ > @@ -25,6 +25,8 @@ config EFI_LOADER > will expose the UEFI API to a loaded application, enabling it to > reuse U-Boot's device drivers. > > + For ARM 32-bit, this adds about 90KB to the size of U-Boot. > + > if EFI_LOADER > > config CMD_BOOTEFI_BOOTMGR Note that we have platforms today with EFI_LOADER without OF_CONTROL, so this isn't strictly the right requirements. What do you think here Heinrich? -- Tom signature.asc Description: PGP signature
[PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
This feature should never have been made available when driver model or devicetree are disabled. Add these as conditions, so that we don't create even more barriers to migration. Add a note about the substantial size increment associated with this option. Signed-off-by: Simon Glass --- Changes in v2: - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL - Note the approximate size of this feature in the help lib/efi_loader/Kconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 6242caceb7f..466abfed300 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running UEFI applications" - depends on OF_LIBFDT && ( \ + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ ARM && (SYS_CPU = arm1136 || \ SYS_CPU = arm1176 || \ SYS_CPU = armv7 || \ @@ -25,6 +25,8 @@ config EFI_LOADER will expose the UEFI API to a loaded application, enabling it to reuse U-Boot's device drivers. + For ARM 32-bit, this adds about 90KB to the size of U-Boot. + if EFI_LOADER config CMD_BOOTEFI_BOOTMGR -- 2.32.0.93.g670b81a890-goog
