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