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.
But I observe that it takes around 60 seconds between
SetVirtualAddressMap() and the first kernel log output.
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>
