[PATCH] configs: layerscape: Disable the EFI_LOADER feature

[Tom Rini]

On Thu, Jul 22, 2021 at 07:00:31PM +0200, Michael Walle wrote:
> Am 2021-07-22 17:26, schrieb Tom Rini:
> > On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
> > 
> > > From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
> > > 
> > > The feature BOOTENV_SHARED_EFI is not supported on layerscape
> > > boards, it didn't result kernel boot crash previously since
> > > there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of
> > > 'boot_efi_binary'.
> > > 
> > > But since the commit f3866909e350 ("distro_bootcmd: call EFI
> > > bootmgr even without having /EFI/boot"), it will cause kernel
> > > boot crash as there isn't a valid fdt_addr and it finially uses
> > > the device tree blob of U-Boot and further cause errors.
> > > 
> > > As this feature is enabled by default for armv7 and armv8, so
> > > disable it explicitly to avoid calling the 'scan_dev_for_efi'.
> > 
> > I'm not thrilled with this.  Why isn't the solution to get and keep in
> > sync the device trees, so that the tree U-Boot has is valid for the
> > kernel?  I'm also open to discussing f3866909e350 more.  But I'm really
> > opposed to disabling EFI_LOADER on modern platforms as that will make
> > adoption of U-Boot in device harder I feel.
> 
> I don't know whats going on with the NXP boards, but the sl28
> is a layerscape board it is working pretty well with EFI boot.
> 
> So why don't you fix the root cause instead of disabling this
> feature?

Having thought a bit more on this, if the U-Boot run-time DTB causes the
kernel to fail that would seem to be a rather big failing on the whole
"DTB is ABI" thing, would it not?  I'm not saying that's not what's
happening, rather I'm noting that it's not supposed to happen and old
DTB + new kernel should work.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210722/52357b14/attachment.sig>