stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
To: Ben Schneider <ben@bens.haus>
Cc: Regressions <regressions@lists.linux.dev>,
	Linux Efi <linux-efi@vger.kernel.org>,
	Stable <stable@vger.kernel.org>, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [REGRESSION] boot fails for EFI boot stub loaded by u-boot
Date: Wed, 18 Oct 2023 11:17:46 +0200	[thread overview]
Message-ID: <817366c2-33e0-4908-90ec-57c63e3eb471@canonical.com> (raw)
In-Reply-To: <CAMj1kXFKe6piagNLdSUhxUhwLB+RfNHqjNWt8-r2CNS-rBdJKA@mail.gmail.com>

On 10/18/23 10:34, Ard Biesheuvel wrote:
> (cc Heinrich)
> 
> Hello Ben,
> 
> Thanks for the report.
> 
> On Wed, 18 Oct 2023 at 03:19, Ben Schneider <ben@bens.haus> wrote:
>>
>> Hi Ard,
>>
>> I have an ESPRESSObin Ultra (aarch64) that uses U-Boot as its bootloader. It shipped from the manufacturer with with v5.10, and I've been trying to upgrade. U-Boot supports booting Image directly via EFI (https://u-boot.readthedocs.io/en/latest/usage/cmd/bootefi.html), and I have been using it that way to successfully boot the system up to and including v6.0.19. However, v6.1 and v6.5 kernels fail to boot.
>>
>> When booting successfully, the following messages are displayed:
>>
>> EFI stub: Booting Linux Kernel...EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value
>> EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary
>> EFI stub: Using DTB from configuration table
>> EFI stub: ERROR: Failed to install memreserve config table!
>> EFI stub: Exiting boot services...
>> [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
>>
>> I suspect many of the above error messages are simply attributable to using U-Boot to load an EFI stub and can be safely ignored given that the system boots and runs fine.

These messages are not typical for launching a kernel via the EFI stub 
from U-Boot. It should look like this:

=> load mmc 0:1 $fdt_addr_r boot/dtb
28846 bytes read in 6 ms (4.6 MiB/s)
=> load mmc 0:1 $kernel_addr_r boot/vmlinuz
53686664 bytes read in 2223 ms (23 MiB/s)
=> setenv bootargs root=/dev/mmcblk0p1 efi=debug earlyprintk 
initrd=boot/initrd.img
=> bootefi $kernel_addr_r $fdt_addr_r
Card did not respond to voltage select! : -110
Failed to load EFI variables
Booting /boot\vmlinuz
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
EFI stub: Loaded initrd from command line option
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

>>
> 
> I suspect that these are not as harmless as you think. How old is the
> u-boot build on this platform?
> 
>> When boot fails (v6.5), the following messages are displayed:
>>
>> EFI stub: Booting Linux Kernel...
>> EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value
>> EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary
>> EFI stub: ERROR: Failed to install memreserve config table!
>> EFI stub: Using DTB from configuration table
>> EFI stub: Exiting boot services...
>> EFI stub: ERROR: Unable to construct new device tree.
>> EFI stub: ERROR: Failed to update FDT and exit boot services
>>
>> In case it's relevant, the device tree for this device is arch/arm64/boot/marvell/armada-3720-espressobin-ultra.dts
>>
> 
> This is a uboot path, right? Not a linux path? Are you sure this DTS
> is compatible with the v6.5 kernel?

There is no arch/arm64/ in U-Boot. Maybe 
arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts?

Best regards

Heinrich

> 
>> Hopefully I've reported this in the correct place or that the information provided is sufficient to get it where it needs to be. Let me know if there is additional information I can provide. I am also able to use the device to test.
>>
> 
> Please add some efi_warn() message inside the update_fdt() routine in
> drivers/firmware/efi/libstub/fdt.c to narrow down which call is
> causing it to return an error. Nothing in that code jumps out to me,
> but we regularly update libfdt in the kernel as well, so it might be a
> change in there that triggers this.


  reply	other threads:[~2023-10-18  9:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18  1:18 [REGRESSION] boot fails for EFI boot stub loaded by u-boot Ben Schneider
2023-10-18  8:34 ` Ard Biesheuvel
2023-10-18  9:17   ` Heinrich Schuchardt [this message]
2023-10-18  9:29     ` Ilias Apalodimas
2023-10-19  1:51       ` Ben Schneider
2023-10-19  7:21         ` Heinrich Schuchardt
2023-10-20  1:25           ` Ben Schneider
2023-10-21  0:07             ` Ben Schneider
2023-10-22 10:17               ` Heinrich Schuchardt
2024-01-31 18:00     ` Ben Schneider

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=817366c2-33e0-4908-90ec-57c63e3eb471@canonical.com \
    --to=heinrich.schuchardt@canonical.com \
    --cc=ardb@kernel.org \
    --cc=ben@bens.haus \
    --cc=linux-efi@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).