FYI: RPi4 (8 GiByte) USB3 vs. head -r363123: still a no-go for booting a USB3 / in my experiments

[Mark Millard]

I did the following experiment mostly just to observe
the current status for sysutils/u-boot-rpi4 based
booting of the RPi4 (with rather modern RPi4 firmware
in use). (I normally use uefi/acpi instead of u-boot,
uefi now at v1.17 . I was hoping to see if u-boot based
also had a bug that uefi contexts have.)

With the kernel on the microsd card (and earlier stage
materials), boot -v reported (before mounting / from
USB3 became relevant):

pci1: <PCI bus> on pcib1
pcib1: allocated bus range (1-1) for rid 0 of pci1
pci1: domain=0, physical bus=1
found-> vendor=0x1106, dev=0x3483, revid=0x01
        domain=0, bus=1, slot=0, func=0
        class=0c-03-30, hdrtype=0x00, mfdev=0
        cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords)
        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
        intpin=a, irq=0
        powerspec 3  supports D0 D3  current D0
        MSI supports 4 messages, 64 bit
        map[10]: type Memory, range 64, base 0, size 12, memory disabled
pcib1: slot 0 INTA is routed to irq 82
xhci0: <XHCI (generic) USB 3.0 controller> irq 82 at device 0.0 on pci1
pcib1: allocated memory range (0xf8000000-0xf8000fff) for rid 10 of xhci0
xhci0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xf8000000
xhci0: 32 bytes context size, 64-bit DMA
xhci0: attempting to allocate 1 MSI vectors (4 supported)
xhci0: using IRQ 83 for MSI
xhci0: MSI enabled
xhci0: Controller reset timeout.
xhci0: XHCI halt/start/probe failed err=18
xhci0: Controller reset timeout.
device_attach: xhci0 attach returned 6
. . .
simplebus2: <xhci at 7e9c0000> mem 0x7e9c0000-0x7eabffff irq 78 disabled compat generic-xhci (no driver attached)

So the USB3 ends up unavailable.

/ would have been from a USB3 SSD if things had worked.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)