[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#988217: u-boot: bootefi causes boot failure with boot.scr

On 2021-05-16, Vagrant Cascadian wrote:
> On 2021-05-07, Vagrant Cascadian wrote:
>> On 2021-04-16, Bastian Germann wrote:
>>> On a Lamobo R1, I can verify 2021.01 versions not to boot with a
>>> default environment. However, 2020.10+dfsg-2 boots. Even though the
>>> original issue has the same outcome, I guess it is caused by something
>>> else.
>> Different enough to warrant it's own bug, cloning...
>>> I figured out my problem is caused by
>>> https://github.com/u-boot/u-boot/commit/f3866909e35074ea6f50226d40487a180de1132f. The
>>> boot_efi_bootmgr will run and read a bad dtb, which makes a boot.scr
>>> boot fail.
>> This would definitely be good to fix in bullseye, but this is quite late
>> in the release cycle.
> After recently upgrading several more systems that turned out to be
> affected by this, I'm bumping the severity of this bug...
>> Will need to test failure and success cases with and without EFI as well
>> as boot.scr and extlinux.conf to make sure this doesn't cause
>> regressions in other boot paths...
> This still needs some work!

I know it is terribly late in the release cycle, but this breaks default
boot on several systems I've tested, and likely to affect others in
reasonable configurations, so I intend to upload a fix with the upstream
the patch very soon.

This could impact debian-installer as it build-depends on it for
armhf/arm64, though I think the chance of regressions are minimal. Is
there a release candidate planned in the immediate future?

I've tested that the fix works for Lamobo-R1, though I haven't yet
tested if it breaks u-boot as an EFI implementation (which seems like
the only significant regression risk). Will test that before uploading.

The upstream patch (which is in debian/patches on the sid branch):

From 82d01f04facef1276cede067efd02d2a731ffe83 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
Date: Sun, 24 Jan 2021 14:34:12 +0000
Subject: [PATCH] efi_loader: switch to non-secure mode later
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some ARMv7 boards using PSCI require to be in secure-mode when booted via
'bootz' or 'bootm'. During distro-boot 'bootefi bootmgr' is called to check
if booting via UEFI is possible.

With the change we change the switch from secure mode to non-secure mode is
moved from the UEFI subsystem setup to just before calling StartImage().

Cc: Jernej Škrabec <jernej.skrabec@gmail.com>
Reported by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
 cmd/bootefi.c              | 4 ++++
 lib/efi_loader/efi_setup.c | 4 ----
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index c8eb5c32b0..81dd8e0284 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -8,6 +8,7 @@
 #include <common.h>
+#include <bootm.h>
 #include <charset.h>
 #include <command.h>
 #include <dm.h>
@@ -338,6 +339,9 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle, void *load_options)
 	efi_uintn_t exit_data_size = 0;
 	u16 *exit_data = NULL;
+	/* On ARM switch from EL3 or secure mode to EL2 or non-secure mode */
+	switch_to_non_secure_mode();
 	/* Call our payload! */
 	ret = EFI_CALL(efi_start_image(handle, &exit_data_size, &exit_data));
 	if (ret != EFI_SUCCESS) {
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 5800cbf6d4..b1c5125032 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -6,7 +6,6 @@
 #include <common.h>
-#include <bootm.h>
 #include <efi_loader.h>
 #include <efi_variable.h>
@@ -188,9 +187,6 @@ efi_status_t efi_init_obj_list(void)
 	/* Allow unaligned memory access */
-	/* On ARM switch from EL3 or secure mode to EL2 or non-secure mode */
-	switch_to_non_secure_mode();
 	/* Initialize root node */
 	ret = efi_root_node_register();
 	if (ret != EFI_SUCCESS)

live well,

Attachment: signature.asc
Description: PGP signature

Reply to: