On Thu, Jul 22, 2021 at 07:08:33PM +0200, Michael Walle wrote:
> Am 2021-07-22 19:02, schrieb 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....@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?
>
> The u-boot dtb isn't really compatible with the kernel dtb, is it? Eg.It's supposed to be. You're supposed to take the kernel dts files, add in as few tweaks as possible (i.e. u-boot,dm-spl and so on). It's a description of the hardware. If you have to make one device tree for the kernel and another slightly different device tree for U-Boot, we've just made it harder for people to add boards, not easier. > the DSA binding is different, the USB binding (might be) is different, eg. > I tried to get the dwc3 driver to work on the LS1028A and it seems that > u-boot (intentionally) needs subnodes to the actual device node in the > DTB, just to load a usb peripheral or usb host mode driver for the > subnode. Thus even, that is an implementation detail which should have > never ended up in the DTB. The enetc binding is different AFAIK. There might be a few other I would think minor tweaks for things like since we don't really support OTG, but that should not cause the kernel to blow up horribly and should be done in such a way that the kernel handles it, or we fix it up again to "neutral" before booting the kernel. > TBH, I'm suprised that the u-boot dtb is passed to linux if there is > no other available. Yes, I think we're now reaching the "surprise" state of EFI support where EFI has a spot for the device tree and if we don't specify one at "bootefi" (or similar) time, the current run time tree populates the spot. This is fine on platforms where we're passed a device tree already for example (think Pi) or other platforms where the dts files are kept in sync well (I think stm32 is a good example here). Much more mixed results elsewhere, apparently. -- Tom
signature.asc
Description: PGP signature
