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 <[email protected]> > > 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 <[email protected]> > > >> Reported-by: Jernej Skrabec <[email protected]> > > >> --- > > >> 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 <[email protected]>
