Hi Steve,
Sorry for the late reply on this.
U-Boot 2022.07-rc6 (Jul 04 2022 - 00:00:00 +0000)
DRAM: 2 GiB
RPI 4 Model B (0xb03115)
I think the HW rev (0xb03115) is to the key to the problem here.
Core: 211 devices, 17 uclasses, devicetree: board
MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In: serial
Out: vidconsole
Err: vidconsole
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... Unexpected XHCI event TRB, skipping... (3db5f620
00000004 01000000 01008401)
BUG at drivers/usb/host/xhci-ring.c:530/abort_td()!
BUG!
resetting ...
This is on my todo to look at. In my testing it has gone away with
something connected via USB.
I tried disconnecting the mouse, keyboard, and Ethernet, but I got
the same failure.
For ref the eth should have little to do with the above on the RPi4 as
it's not connected via USB like previous generations.
I then tried just disconnecting the HDMI monitor, while leaving
everything else connected. In that case I am able to get further, but then I start
getting timeout messages from dracut:
The HDMI bit is weird, but I'll skip that for the moment, I'm guessing
it's more related to what is connected, possibly where, to USB.
[ 368.423014] dracut-initqueue[441]: Warning: dracut-initqueue:
timeout, still waiting for following initqueue hooks:
[ 368.471849] dracut-initqueue[441]: Warning:
/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f6c12ffc9-6ea9-457c-9acf-7a886798e99c.sh:
"if ! grep -q After=remote-fs-pre.target
/run/systemd/generator/systemd-cryptsetup(a)*.service 2>/dev/null; then
[ 368.472914] dracut-initqueue[441]: [ -e
"/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ]
[ 368.473753] dracut-initqueue[441]: fi"
[ 368.545042] dracut-initqueue[441]: Warning: dracut-initqueue: starting timeout
scripts
[ 370.304891] dracut-initqueue[441]: Warning: dracut-initqueue: timeout, still waiting
for following initqueue hooks:
[ 370.353412] dracut-initqueue[441]: Warning:
/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f6c12ffc9-6ea9-457c-9acf-7a886798e99c.sh:
"if ! grep -q After=remote-fs-pre.target
/run/systemd/generator/systemd-cryptsetup(a)*.service 2>/dev/null; then
[ 370.354565] dracut-initqueue[441]: [ -e
"/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ]
[ 370.355428] dracut-initqueue[441]: fi"
[ 370.426159] dracut-initqueue[441]: Warning: dracut-initqueue: starting timeout
scripts
[ 371.795792] dracut-initqueue[441]: Warning: dracut-initqueue: timeout, still waiting
for following initqueue hooks:
[ 371.845592] dracut-initqueue[441]: Warning:
/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f6c12ffc9-6ea9-457c-9acf-7a886798e99c.sh:
"if ! grep -q After=remote-fs-pre.target
/run/systemd/generator/systemd-cryptsetup(a)*.service 2>/dev/null; then
[ 371.846757] dracut-initqueue[441]: [ -e
"/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ]
[ 371.847604] dracut-initqueue[441]: fi"
[ 371.922589] dracut-initqueue[441]: Warning: dracut-initqueue: starting timeout
scripts
Next, I tried Fedora-KDE-Rawhide-20220717.n.0.aarch64.raw.xz and
Fedora-Workstation-Rawhide-20220717.n.0.aarch64.raw.xz. Amazingly, they are able to get
past the XHCI error even with the HDMI monitor connected. However, they still fail later
in the startup process with the same dracut messages that I showed above.
I then tried Fedora-Server-Rawhide-20220717.n.0.aarch64.raw.xz. It booted with
everything connected. It got to the initial configuration menu, let me set the root
password, and booted to a login prompt, which worked perfectly.
As a final test, I tried the Fedora-Minimal-Rawhide-20220717.n.0.aarch64.raw.xz and
Fedora-KDE-Rawhide-20220717.n.0.aarch64.raw.xz images on a USB flash stick instead of on a
uSD card. Both worked perfectly.
So, there is something bizarre happening with uSD cards with most of the images I tested.
The only image that works for me on a uSD card is the Server image. Note that I tried
several different uSD cards - Samsung, SanDisk, and a "no name" card, and got
consistent results, so I don't think the uSD cards are at fault.
I tried two different USB flash sticks, a SanDisk and a Transcend - both worked
perfectly.
So I think the different images are purely chance, they shouldn't make
any difference.
I mentioned the HW rev above, the hex value tells me it's Rev 1.5 of
the 2gb 4B. Since rev 1.4 they've been able to run at 1.8ghz like the
RPi400 instead of the 1.5ghz of the older revs, but this came with
some minor design changes, this in turn has caused issues in
particular around the MMC stability, the device works using "firmware
DT" but not the vanilla upstream kernel DT.
I think we now have a fix headed upstream into U-Boot that should
allow this to work, you can grab the latest U-Boot builds from koji
and update them or it should be fixed in the next rawhide or F-37
generated images (probably tomorrow).
Peter