https://bugzilla.suse.com/show_bug.cgi?id=1207562 https://bugzilla.suse.com/show_bug.cgi?id=1207562#c19 --- Comment #19 from Chester Lin <chester.lin@suse.com> --- Hi Stefan and Pruessmann, (In reply to Stefan Seyfried from comment #17)

I can try different things, but I'd need instructions what to do where and when.

My U-boot knowledge is from embedded systems that do not use UEFI stuff at all ;-) and from a time when there were no such things as "device trees" but instead separate kernels for different hardware configurations were built :-)

So what I wanted to say... I don't even know what a "runtime FDT" is, much less how I would check if it declares reserved memory ;-)

The bdinfo would need to come from the "broken" U-boot? or can I use a "good", working version?

Just found that I can reproduce this issue as well [Snapshot20230130] based on the following configuration: 1. Run rpi-imager to turn usb-boot on. (BOOT-EEPROM updated) 2. Directly boot from USB stick and then the issue happens. Running the 'usb_boot' script in u-boot console has the same symptom. The console log is attached in #Comment18. But booting from mmc and then 'run usb_boot' just works fine. Compared to mmc boot, indeed there's one more reserved region in USB boot although none of them occupies address 0x00080000 at the beginning, which should be the default load address of grub2 for the distro bootcmd: ---- U-Boot> bdinfo <snip> lmb_dump_all: memory.cnt = 0x2 memory[0] [0x0-0x3defffff], 0x3df00000 bytes flags: 0 memory[1] [0x40000000-0xfbffffff], 0xbc000000 bytes flags: 0 reserved.cnt = 0x6 reserved[0] [0x0-0x7ffff], 0x00080000 bytes flags: 4 reserved[1] [0x3c820000-0x3defffff], 0x016e0000 bytes flags: 0 reserved[2] [0x3d8262d0-0x3dcfffff], 0x004d9d30 bytes flags: 0 reserved[3] [0x3ee62be0-0x3ee62fdf], 0x00000400 bytes flags: 4 reserved[4] [0x3ee63020-0x3ee63067], 0x00000048 bytes flags: 4 reserved[5] [0x40000000-0xfbffffff], 0xbc000000 bytes flags: 0 ---- However, I also tried to manually load grub2 and then ran bootefi directly, and it just worked well: ---- U-Boot 2023.01 (Jan 27 2023 - 00:00:00 +0000) DRAM: 991 MiB (effective 3.9 GiB) RPI 4 Model B (0xc03111) Core: 210 devices, 17 uclasses, devicetree: board MMC: mmcnr@7e300000: 1, mmc@7e340000: 0 Loading Environment from FAT... Card did not respond to voltage select! : -110 ** Bad device specification mmc 0 ** In: serial Out: serial Err: serial Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 U-Boot> load usb 0:1 ${kernel_addr_r} /EFI/BOOT/bootaa64.efi 1574768 bytes read in 21 ms (71.5 MiB/s) U-Boot> bootefi ${kernel_addr_r} ${fdtcontroladdr} sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_set_clock: Timeout to wait cmd & data inhibit sdhci_send_command: MMC: 1 busy timeout increasing to: 200 ms. sdhci_send_command: MMC: 1 busy timeout increasing to: 400 ms. sdhci_send_command: MMC: 1 busy timeout increasing to: 800 ms. sdhci_send_command: MMC: 1 busy timeout increasing to: 1600 ms. sdhci_send_command: MMC: 1 busy timeout increasing to: 3200 ms. sdhci_send_command: MMC: 1 busy timeout. Card did not respond to voltage select! : -110 No EFI system partition Booting /\EFI\BOOT\bootaa64.efi ethernet@7d580000 Waiting for PHY auto negotiation to complete.... ---- I doubt that something in the default boot scan/process might cause an additional reservation on 0x00080000 at runtime since the manual load & bootefi commands seem to work fine.

The problem with the broken one is that it is already in the TFTP BOOTP stage once the HDMI output stabilizes and once it is there, no keyboard input seems to do anything at all. So I'd need to set up a serial console etc and since this would be possible, it's quite some effort here and I'd leave that experiment to someone else experiencing this issue who already might have everything set up.

-- You are receiving this mail because: You are on the CC list for the bug.