[PATCH] configs: layerscape: Disable the EFI_LOADER feature

[Michael Walle]

Am 2021-07-26 09:01, schrieb Z.Q. Hou:
> Hi Michael,
> 
>> -----Original Message-----
>> From: Michael Walle <michael at walle.cc>
>> Sent: 2021年7月23日 1:01
>> To: Tom Rini <trini at konsulko.com>
>> Cc: Z.Q. Hou <zhiqiang.hou at nxp.com>; Heinrich Schuchardt
>> <xypron.glpk at gmx.de>; u-boot at lists.denx.de; Priyanka Jain
>> <priyanka.jain at nxp.com>
>> Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER 
>> feature
>> 
>> 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.
> 
> Do you mean the EFI boot work well on sl28?
This, for example, I can boot the debian installer out-of-the-box,
given that the fdtfile variable is set correctly.

> Or the EFI boot doesn't break other boot ways?
> 
> In my case, there are 4 MMC partitions and a boot script with boot
> images in the 2nd partition, while nothing in the 1st partition. So
> the expected boot flow is the 'bootcmd_mmc0' scan the 1st partition
> and find it's not bootable and then the 2nd partition and boot with
> the script. But actually the 'scan_dev_for_efi' got problem when scan
> the 1st partition, as the u-boot DTB is used in 'bootefi bootmgr' and
> result in some error related to the DTB.

As mentioned in the other mail, I'm not sure why "bootefi bootmgr"
does something at all, because AFAIK it needs the BootOrder/BootNext
variables. Heinrich, please correct me if I'm wrong.

> Actually, if give a readable but invalid 'fdt_addr' in env, the EFI
> boot can also be skipped during the scan of the 1st partition.
> Actually on some Layerscape boards the provided env 'fdt_addr' with a
> non-readable address, and on other boards a readable 'fdt_addr'. Seems
> the patch author copy them from somewhere but didn't cause issue that
> time. But this is just a workaround, the EFI boot should not cause
> problem during the scan phase when there isn't needed components in
> one of these partitions.

What exactly is going wrong? Is linux booting at all? Or does the
bootloader abort?

And why don't you fix the fdt_addr then? Shouldn't it be unset if
there is no actual device tree present in a ROM section? (I don't
say there isn't another underlying problem when you use an invalid
fdt_addr).

-michael