[U-Boot] [PATCH 2/2] efi_loader: enable EFI_LOADER on arm1136 and arm1176

[Tom Rini]

On Tue, Nov 19, 2019 at 07:11:46PM +0100, Heinrich Schuchardt wrote:
> On 11/19/19 4:22 PM, Tom Rini wrote:
> > On Tue, Nov 19, 2019 at 04:35:57AM +0100, Heinrich Schuchardt wrote:
> > > With an implementation for allow_unaligned() available for arm1136 and
> > > arm1176 UEFI can be supported on these architectures.
> > > 
> > > Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> > > ---
> > >   lib/efi_loader/Kconfig | 6 ++++--
> > >   1 file changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > index 2f40e485ef..7984d6f42d 100644
> > > --- a/lib/efi_loader/Kconfig
> > > +++ b/lib/efi_loader/Kconfig
> > > @@ -1,8 +1,10 @@
> > >   config EFI_LOADER
> > >   	bool "Support running UEFI applications"
> > >   	depends on OF_LIBFDT && ( \
> > > -		ARM && (SYS_CPU = armv7 || \
> > > -			SYS_CPU = armv8) || \
> > > +		ARM && (SYS_CPU = arm1136 || \
> > > +			SYS_CPU = arm1176 || \
> > > +			SYS_CPU = armv7   || \
> > > +			SYS_CPU = armv8)  || \
> > >   		X86 || RISCV || SANDBOX)
> > >   	# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
> > >   	depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
> > 
> > My concern is that while it's goodk and important we're correcting the
> > dependencies for ARM, non-ARMv7 hardware is much more legacy than new
> > design and we maybe don't want to have it enabled by default there.  One
> > of the biggest pieces of feedback I have gotten over the overall EFI
> > support is that it being on by default on legacy systems causes a lot of
> > unwanted size growth.  Does Kconfig work sanely with something like:
> > 	default y if !ARM
> > 	default y if ARM && (SYS_CPU = armv7 || SYS_CPU == arv8)
> > ?  Then we could allow other older ARM systems to enable it still and
> > now function (again, good work) without the size growth by default.
> > Thanks!
> 
> These are the only ARM11 boards:
> 
> evb-ast2500_defconfig
> flea3_defconfig
> integratorcp_cm1136_defconfig
> mx31pdk_defconfig
> mx35pdk_defconfig
> rpi_0_w_defconfig
> rpi_defconfig
> woodburn_defconfig
> woodburn_sd_defconfig
> 
> Which one poses a problem?

Of those, I would assume the two Pi boards might opt-in, maybe the
aspeed board and not the rest.

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