| Message ID | 20171010122309.25313-12-robdclark@gmail.com |
|---|---|
| State | Deferred |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | efi_loader: patches for Shell.efi | expand |
On 10/10/2017 02:23 PM, Rob Clark wrote: > These devices have small image size limits, so exclude EFI_LOADER to > help avoid exceeding limits. > > Signed-off-by: Rob Clark <robdclark@gmail.com> > --- > lib/efi_loader/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index d2b6327119..6e22940da5 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig > @@ -1,6 +1,6 @@ > config EFI_LOADER > bool "Support running EFI Applications in U-Boot" > - depends on (ARM || X86) && OF_LIBFDT > + depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD > default y > help > Select this option if you want to run EFI applications (like grub2) > I understand that with the progress we make on EFI implementation and other parts of U-Boot the U-Boot image size is growing too big for direct loading by the primary boot loader. The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig refers to a board with 512 MB RAM. So I think completely disabling EFI is not the solution. Instead building an SPL should be enabled for this architecture when the image is becoming too big for direct load. I am copying in the KIRKWOOD maintainers go get their view. Best regards Heinrich
On Tue, Oct 10, 2017 at 6:28 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > On 10/10/2017 02:23 PM, Rob Clark wrote: >> >> These devices have small image size limits, so exclude EFI_LOADER to >> help avoid exceeding limits. >> >> Signed-off-by: Rob Clark <robdclark@gmail.com> >> --- >> lib/efi_loader/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig >> index d2b6327119..6e22940da5 100644 >> --- a/lib/efi_loader/Kconfig >> +++ b/lib/efi_loader/Kconfig >> @@ -1,6 +1,6 @@ >> config EFI_LOADER >> bool "Support running EFI Applications in U-Boot" >> - depends on (ARM || X86) && OF_LIBFDT >> + depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD >> default y >> help >> Select this option if you want to run EFI applications (like >> grub2) >> > > I understand that with the progress we make on EFI implementation and other > parts of U-Boot the U-Boot image size is growing too big for direct loading > by the primary boot loader. > > The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig > refers to a board with 512 MB RAM. > > So I think completely disabling EFI is not the solution. > Instead building an SPL should be enabled for this architecture when the > image is becoming too big for direct load. > > I am copying in the KIRKWOOD maintainers go get their view. > I'm defn open to alternatives.. I don't know too much about what the limit was on these boards, other than we were close to it before, and the additional uefi proto's add <4k to the image size, which was enough to push it over the limit. Since this was effecting only a few boards, I went with this.. if it is only a temporary fix that can be removed soon, or if someone can do something better with a separate SPL build in the near term, that would be great. BR, -R
(Adding Albert as maintainer again) On 11.10.2017 00:50, Rob Clark wrote: > On Tue, Oct 10, 2017 at 6:28 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: >> On 10/10/2017 02:23 PM, Rob Clark wrote: >>> >>> These devices have small image size limits, so exclude EFI_LOADER to >>> help avoid exceeding limits. >>> >>> Signed-off-by: Rob Clark <robdclark@gmail.com> >>> --- >>> lib/efi_loader/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig >>> index d2b6327119..6e22940da5 100644 >>> --- a/lib/efi_loader/Kconfig >>> +++ b/lib/efi_loader/Kconfig >>> @@ -1,6 +1,6 @@ >>> config EFI_LOADER >>> bool "Support running EFI Applications in U-Boot" >>> - depends on (ARM || X86) && OF_LIBFDT >>> + depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD >>> default y >>> help >>> Select this option if you want to run EFI applications (like >>> grub2) >>> >> >> I understand that with the progress we make on EFI implementation and other >> parts of U-Boot the U-Boot image size is growing too big for direct loading >> by the primary boot loader. >> >> The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig >> refers to a board with 512 MB RAM. >> >> So I think completely disabling EFI is not the solution. >> Instead building an SPL should be enabled for this architecture when the >> image is becoming too big for direct load. >> >> I am copying in the KIRKWOOD maintainers go get their view. >> > > I'm defn open to alternatives.. I don't know too much about what the > limit was on these boards, other than we were close to it before, and > the additional uefi proto's add <4k to the image size, which was > enough to push it over the limit. Since this was effecting only a few > boards, I went with this.. if it is only a temporary fix that can be > removed soon, or if someone can do something better with a separate > SPL build in the near term, that would be great. I personally have not used any Kirkwood based platforms in the last few years (and don't have access to one). And I don't see activities here from mother developers either. As adding SPL support is not trivial, frankly I don't see that this will be done anytime soon if at all. Perhaps the image size can be reduced by removing other features or interfaces from the OPENRD platform instead (CMD_MII, JFFS2, ...)? Thanks, Stefan
On 11.10.17 09:07, Stefan Roese wrote: > (Adding Albert as maintainer again) > > On 11.10.2017 00:50, Rob Clark wrote: >> On Tue, Oct 10, 2017 at 6:28 PM, Heinrich Schuchardt >> <xypron.glpk@gmx.de> wrote: >>> On 10/10/2017 02:23 PM, Rob Clark wrote: >>>> >>>> These devices have small image size limits, so exclude EFI_LOADER to >>>> help avoid exceeding limits. >>>> >>>> Signed-off-by: Rob Clark <robdclark@gmail.com> >>>> --- >>>> lib/efi_loader/Kconfig | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig >>>> index d2b6327119..6e22940da5 100644 >>>> --- a/lib/efi_loader/Kconfig >>>> +++ b/lib/efi_loader/Kconfig >>>> @@ -1,6 +1,6 @@ >>>> config EFI_LOADER >>>> bool "Support running EFI Applications in U-Boot" >>>> - depends on (ARM || X86) && OF_LIBFDT >>>> + depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD >>>> default y >>>> help >>>> Select this option if you want to run EFI applications (like >>>> grub2) >>>> >>> >>> I understand that with the progress we make on EFI implementation and >>> other >>> parts of U-Boot the U-Boot image size is growing too big for direct >>> loading >>> by the primary boot loader. >>> >>> The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig >>> refers to a board with 512 MB RAM. >>> >>> So I think completely disabling EFI is not the solution. >>> Instead building an SPL should be enabled for this architecture when the >>> image is becoming too big for direct load. >>> >>> I am copying in the KIRKWOOD maintainers go get their view. >>> >> >> I'm defn open to alternatives.. I don't know too much about what the >> limit was on these boards, other than we were close to it before, and >> the additional uefi proto's add <4k to the image size, which was >> enough to push it over the limit. Since this was effecting only a few >> boards, I went with this.. if it is only a temporary fix that can be >> removed soon, or if someone can do something better with a separate >> SPL build in the near term, that would be great. > > I personally have not used any Kirkwood based platforms in the last few > years (and don't have access to one). And I don't see activities here > from mother developers either. As adding SPL support is not trivial, > frankly I don't see that this will be done anytime soon if at all. > > Perhaps the image size can be reduced by removing other features or > interfaces from the OPENRD platform instead (CMD_MII, JFFS2, ...)? If it's too much work to make EFI_LOADER work on these platforms, I guess it's ok to disable it just for them. Given how dated they are, chances are pretty slim that enabling EFI_LOADER by default will give us a U-Boot copy on the device that supports it straight from the factory ;). However, I would ideally prefer to see that happen in the respective defconfigs, not in Kconfig. Alex
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index d2b6327119..6e22940da5 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" - depends on (ARM || X86) && OF_LIBFDT + depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD default y help Select this option if you want to run EFI applications (like grub2)
These devices have small image size limits, so exclude EFI_LOADER to help avoid exceeding limits. Signed-off-by: Rob Clark <robdclark@gmail.com> --- lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)