USB3.0 on Rapsberry pi Compute Module 5

Product support balenaOS
, ,
2

Update: root cause narrowed down with kernel-level evidence.

This is not a missed hotplug interrupt. The SuperSpeed upstream link between the RP1 and the USB5744 never trains under balenaOS, and the failure has two distinct states, visible in xHCI debugfs:

Wedged state (what we were in during all previous hotplug tests). The SS root port sits in Polling with repeated warm resets:

/sys/kernel/debug/usb/xhci/xhci-hcd.1/ports/port03/portsc:
0x002802e0 Powered Not-connected Disabled Link:Polling PortSpeed:0 Change: WRC PRC

In this state a hotplugged USB 3.0 device asserts SS terminations toward the hub and there is no fallback to HS, so nothing ever reaches the host. dmesg stays completely silent. The 0424:5744 SS hub instance never appears on the 5 Gbps bus.

Host-side recovery does NOT clear it. All tested and failed:

  • forcing runtime PM on for all root hubs and the xHCI platform devices
  • unbind/bind of xhci-hcd.1 with the device present (port returns to Polling, In-Reset)
  • root port disable/enable via usbN-port1/disable

Settled state. Cycling VBUS_DET to the hub (GPIO 611, USB_VBUS_EN) makes the hub re-attach, fail SS training quickly, and settle as a USB2-only hub (port03 goes to Link:RxDetect, terminations withdrawn). In this state USB 3.0 stick hotplug works perfectly, enumerating at 480M:

usb 4-1.4: new high-speed USB device number 10 using xhci-hcd
usb 4-1.4: Product: SanDisk 3.2Gen1
sd 0:0:0:0: [sda] Attached SCSI removable disk

So the practical failure is: SS training fails, the port/hub wedges in an endless Polling/warm-reset loop, and while wedged even the HS fallback path for downstream hotplugs is blocked.

Our workaround is now a one-shot VBUS cycle at boot (after the xHCI is up) plus a supervisor that only re-cycles if port03 shows persistent Polling. Hotplug is event-driven again after that.

Remaining question for the balena team: on RPiOS 6.12.75 the same hardware handles this cleanly, and we still need to verify whether SS actually trains there (0424:5744 present) or whether RPiOS just handles the failed-training fallback gracefully. Either way the delta is kernel-side. Is a kernel bump past 6.12.61 planned for this device type, and is there a recommended path to test a newer KERNEL_REVISION via balena-raspberrypi?