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

[Jernej Škrabec]

Hi!

Dne nedelja, 24. januar 2021 ob 09:27:02 CET je Heinrich Schuchardt 
napisal(a):
> 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.

I observed issue on OrangePi Plus2E which has eMMC. At that time, there was 
Android on it. If I disabled eMMC support in U-Boot, boot went just fine.

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

I guess this is another issue. It never booted in my case. It stopped right 
after "Starting kernel...".

Best regards,
Jernej

> 
> 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>