USB3.0 on Rapsberry pi Compute Module 5

Product support balenaOS
, ,
1

Dear Support team,

Board: Oratek Tofu5 with CM5
OS: balenaOS 6.12.61-v8-16k
Comparison: Raspberry Pi OS 6.12.75+rpt-rpi-2712

Summary

On the Tofu5 carrier, USB 3.0 devices plugged into a Microchip USB5744 hub (0424:2744) fail to enumerate on hot-plug under balenaOS. USB 2.0 devices hot-plug fine. The same hardware works correctly on RPiOS. This points to missing RP1 xHCI patches in the balenaOS kernel.

What works and what doesn’t

Scenario balenaOS RPiOS
USB 2.0 device hot-plug Works Works
USB 3.0 device hot-plug Fails Works
USB 3.0 device present at boot Works (with workaround) Works

The test device is a SanDisk 3.2Gen1 (0781:55a9). Even though it ultimately runs at 480M through this hub, it asserts SuperSpeed signalling on plug-in. The hub’s SS downstream port state machine then gets stuck because the SS upstream link (Bus 05) is never trained. There is no fallback to HS on hot-plug. On RPiOS the same sequence works cleanly.

On a bad hot-plug, dmesg -w is completely silent – no port status change event, no error, nothing. The host is never signalled.

Isolation evidence

We ruled out:

  • The drive itself (works on good boots, works on RPiOS)
  • The USB5744 hub (always enumerates, all 4 ports reported)
  • RP1 firmware (identical version on both OSes, loads every boot)
  • Autosuspend (setting power/control=on on the hub makes no difference)
  • The DWC2 overlay (already present in balenaOS config)
  • authorized_default=0 on the SS bus (no effect)

The single variable that explains the difference is the kernel. RPiOS ships 6.12.75+rpt-rpi-2712 which carries RP1-specific xHCI patches. balenaOS ships mainline 6.12.61-v8-16k which does not.

Workaround in place

We are currently working around the cold-boot detection issue with a privileged container that cycles GPIO 611 (USB_VBUS_EN, RP1 GPIO 42) at startup to force a clean USB5744 reset. This fixes boot-time detection but cannot fix hot-plug since that is a kernel interrupt handling issue.

For hot-plug we have a watchdog that detects a missing drive and cycles the GPIO, giving ~10s detection latency. This is not suitable for production.

Question

We’ve exhausted sysfs-level workarounds and the kernel version is the most obvious difference we haven’t been able to test. Before going deeper we wanted to check: has anyone seen this before with the USB5744 on CM5 under balenaOS, and does the team have any ideas on where to look next?

Thanks in advance

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?

3

hey @antoineschmider , thanks for the report. I have opened a pull request to update to the latest head on the stable 6.12 branch, once it merges and test pass it will deploy a new version to the platform.