Alpha: TUSB8041 SuperSpeed uplink never trains (Link:Polling); all external USB ports limited to 480 Mb/s

Summary

On our alpha SystemCore, the USB 3.0 (SuperSpeed) uplink between the BCM2712/RP1 and the onboard TI TUSB8041 4-port hub never links up. The RP1's SuperSpeed root port sits permanently in Link:Polling (far-end termination detected, link training never completes), so the hub enumerates only its USB 2.0 half (0451:8142; the 0451:8140 SuperSpeed half never appears) and all four external USB-A ports run at 480 Mb/s, regardless of device.

Same OS image on a Raspberry Pi 5 (stock board) trains SuperSpeed normally with the same device and cable, so this looks like a carrier-board / PHY-tuning issue rather than software.

Environment

• Alpha SystemCore (model string: Raspberry Pi Compute Module 5 Rev 1.0), image limelightosr-2027.0.0-alpha13, kernel 6.12.77-v8-16k
• Device tree in use: stock bcm2712-rpi-cm5-cm5io.dtb; both RP1 snps,dwc3 controllers status = okay, usb3-lpm-capable
• Test device: a self-powered USB 3.0-capable camera with its own USB 3 cable (SuperSpeed-capable; trains at 5000M on a Pi 5, see Control)

Evidence

lsusb -t — hub and everything behind it at 480M; both 5000M roots empty:

/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/2p, 480M
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M        <- TUSB8041, 0451:8142 only
        |__ Port 004: Dev 005, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M   <- USB3-capable camera
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M

xhci root-port registers (/sys/kernel/debug/usb/xhci/*/ports/*/portsc):

xhci-hcd.1/ports/port01/portsc: 0x00000e03 Powered Connected Enabled Link:U0 PortSpeed:3      <- hub's USB2 half
xhci-hcd.1/ports/port03/portsc: 0x0a0002e0 Powered Not-connected Disabled Link:Polling        <- SS lane to hub: stuck training
xhci-hcd.0/ports/port03/portsc: 0x0a0002a0 Powered Not-connected Disabled Link:RxDetect       <- other SS lane: nothing attached

Polling on hcd.1 means the PHY does detect a receiver termination on the SS pair (the hub's SS upstream is physically there) but TS1/TS2 training never reaches U0. The hcd.0 SS port, by contrast, shows plain RxDetect (genuinely unconnected).

/sys/bus/usb/devices/usb2/2-0:1.0/usb2-port1/state and usb4-port1/state: not attached at all times; no port-related errors in dmesg.

Control

Same image flashed to a Raspberry Pi 5, same camera and cable, camera powered on while attached:

usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
usb 4-1: New USB device found (same camera)

(speed = 5000M). So the device, cable, kernel and driver stack are fine; only the SystemCore's hub uplink fails.

Impact

• Every external port is effectively USB 2.0 (~35 MB/s shared across the hub). Our USB3 camera is bandwidth-capped to ~21 fps of its 29 fps and its stream collapses after ~80 s on this board; the same stream runs indefinitely on the Pi 5 at SuperSpeed.
• May be related to #348 (MJPEG "premature end of data segment" at high frame rates, worse with larger frames) if those cameras share the same 480M ceiling.

Questions

1. Is the TUSB8041 SuperSpeed uplink expected to work on alpha hardware? On beta?
2. If it is, could this be a PHY tuning issue (the board runs the reference CM5IO device tree, i.e. reference-board SS PHY settings) rather than layout?

Happy to run any further diagnostics on this unit. Commands used are all read-only (lsusb -t, portsc via debugfs, sysfs port state, /proc/device-tree).

Start with the captured lsusb -t output, xhci portsc registers, sysfs port state, dmesg, and the stock bcm2712-rpi-cm5-cm5io.dtb used on the alpha SystemCore. Compare these results with the Raspberry Pi 5 control case and determine whether the TUSB8041 uplink failure is attributable to PHY settings or board hardware; done means the cause and expected alpha/beta behavior are documented.