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@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@arm.com Reported-by: Jernej Skrabec jernej.skrabec@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@chromium.org