[RFC PATCH] arm: EFI: Disallow EFI bootmgr when providing PSCI

[Heinrich Schuchardt]

On 1/24/21 3:03 AM, Simon Glass wrote:
> On Fri, 22 Jan 2021 at 05:05, Andre Przywara <andre.przywara at arm.com> wrote:
>>
>> When "bootefi bootmgr" is run, it switches the CPU into non-secure
>> state. This breaks platforms like 32-bit Allwinner boards that rely on
>> running in secure state until late in the process, when they install
>> the PSCI handler in secure memory and drop into non-secure state.
>> They hang just before entering the kernel, after the "Starting the
>> kernel" message.

Dear Andre,

thank you for reporting the issue.

I have an Orange Pi PC with a 32 bit Allwinner CPU.
orangepi_pc_defconfig has CONFIG_ARMV7_PSCI=y.

I use origin/master (e716c9022970dac9b) and the Orange PI boots
successfully using GRUB EFI into Linux 5.9.

But I observe that it takes around 60 seconds between
SetVirtualAddressMap() and the first kernel log output.

EFI stub: Exiting boot services and installing virtual address map...

EHCI failed to shut down host controller.
<<< 60 seconds waiting without output >>>>

[    0.000000] Booting Linux on physical CPU 0x0

I have seen this regression since some time last year.

Reverting patch f3866909e350 does not solve the problem.
Reverting to U-Boot v2020.01 does not solve the problem.

Reverting the kernel from v5.9 to 5.4 solves the problem both for U-Boot
v2020.01 as well as for U-Boot v2021.01.

I have poked around with some pre-built kernels from
http://snapshot.debian.org/package/linux:

Linux 5.9.11 - 1 minute delay
Linux 5.8.14 - 1 minute delay
Linux 5.7.17 - no delay
Linux 5.6.14 - no delay
Linux 5.5.17 - no delay
Linux 5.4.19 - no delay

It seems that some change in Linux is causing the regression. Could you,
please, try to analyze it in more depth.

Best regards

Heinrich

>>
>> Commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without
>> having /EFI/boot") changed the order of EFI probing, so the EFI bootmgr
>> is now *always* run, resulting in the default distro boot commands now
>> *always* failing, even in the total absence of any UEFI directories or
>> boot files.
>>
>> So use the newly added build option to disable the EFI bootmgr, which
>> makes those boards boot again using the distro boot commands.
>> Explicitly calling "bootefi bootmgr" still breaks the boot, though.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> Reported-by: Jernej Skrabec <jernej.skrabec at siol.net>
>> ---
>> Hi,
>>
>> the above is the result of my analysis, happy to stand corrected in
>> case I missed something. I know that this is not a proper solution,
>> but it's an effective stop-gap measure to fix all those boards. It looks
>> like a proper solution would either be:
>> - Let the EFI bootmgr run in the current security state.
>> - Install the PSCI handlers early in U-Boot.
>>
>> Both solutions sound rather involved, so probably require more time.
>> But we need to fix this breakage now.
>>
>> Cheers,
>> Andre
>>
>>   lib/efi_loader/Kconfig | 1 +
>>   1 file changed, 1 insertion(+)
>
> Reviewed-by: Simon Glass <sjg at chromium.org>
>