Am 2021-07-26 09:01, schrieb Z.Q. Hou:
Hi Michael,
-----Original Message-----
From: Michael Walle <mich...@walle.cc>
Sent: 2021年7月23日 1:01
To: Tom Rini <tr...@konsulko.com>
Cc: Z.Q. Hou <zhiqiang....@nxp.com>; Heinrich Schuchardt
<xypron.g...@gmx.de>; u-boot@lists.denx.de; Priyanka Jain
<priyanka.j...@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....@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
