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@*.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@*.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@*.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 _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
