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.przyw...@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.przyw...@arm.com> > >> Reported-by: Jernej Skrabec <jernej.skra...@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 <s...@chromium.org> -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/2480020.2OzWpZbi63%40jernej-laptop.
