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