Comment # 19
on bug 1207562
from Chester Lin
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.