[linux-sunxi] Re: [RFC PATCH] arm: EFI: Disallow EFI bootmgr when providing PSCI

[Jernej Škrabec]

Dne nedelja, 24. januar 2021 ob 09:33:15 CET je Jernej Škrabec napisal(a):
> 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.

Just one clarification - issue here is that "bootefi bootmgr" command
when unsuccessful breaks booting with bootm command.

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