USB3.0 device were recognized as USB2.0

[vewe-richard]

VERSION:

$ cat /etc/distiller-platform-info
DISTILLER_PLATFORM_VERSION=2.1.0                            
DISTILLER_INSTALL_DATE=2026-01-26T15:32:37-05:00  

below message from Kevin in slack

1. Symptom
Only when the USB Type-C plug is inserted in one specific orientation, the device can be detected as USB 3.0.
When inserted in the opposite orientation, the device can only operate in USB 2.0 mode.
2. Root Cause Analysis
The fundamental root cause is a timing conflict between USB VBUS power enable and cable orientation detection/switching.
Expected / Correct Timing
CC logic chip detects CC1/CC2 → CC logic chip switches orientation → orientation switch confirmed OK → then enable VBUS power to USB Type-C
Flowchart (translated)
[CC logic chip detects CC1/CC2 pins]
→ [CC logic chip decides whether orientation switching is needed]
→ (Yes) [CC logic chip switches orientation]
→ [Control Power Switch to supply VBUS to USB Type-C]
If (No) → directly [Control Power Switch to supply VBUS to USB Type-C]
3. Current / Actual Timing (Observed)
After system boot, CM5’s VBUS_EN signal is immediately pulled high, causing the Type-C port to continuously provide power (VBUS).
At that moment, the orientation detection and switching process (handled by HD3SS3220) is not completed or not stable yet.
Because power is applied too early, the USB device is powered and starts communicating before the host has correctly identified and configured the high-speed (USB 3.0) signal path.
As a result, during enumeration the host fails to complete the USB 3.0 handshake, and is forced to fall back to USB 2.0 mode.
4. Conclusion
The current design violates the correct USB Type-C sequence:
:white_check_mark: Correct sequence should be: “Detect orientation first, then enable VBUS.”
Therefore, the VBUS enable signal (VBUS_EN) must only become active after the CC logic chip confirms the cable orientation and outputs stable control signals, ensuring the USB 3.0 SuperSpeed signal routing is correctly configured before power/connection is established.
[@Utsav Balar](https://pamir-hq.slack.com/team/U08GWNCKP8C) [@Jiang](https://pamir-hq.slack.com/team/U0A2ETKJUAF)
Please check CM5’s VBUS_EN behavior and timing at boot.
We need VBUS_EN to be delayed/gated until HD3SS3220 finishes CC orientation detection & switching, otherwise USB3 negotiation may fail in one plug orientation and fall back to USB2. (edited)

[vewe-richard]

After verified a script, summary from claude

USB-C Orientation Detection Issue - Session Summary

Problem Description

• Hardware: Raspberry Pi CM5 (Debian 13)
• Issue: USB-C port only supports USB 3.1 SuperSpeed in one plug orientation; the other orientation falls back to USB 2.0 (480Mbps)
• Root Cause: VBUS_EN (GPIO 611) is pulled high too early during boot, before the CC (Configuration Channel) logic can properly detect cable orientation and configure the USB 3.0 signal path

Expected vs Actual Timing

• Correct sequence: Detect CC orientation → Configure signal routing → Enable VBUS
• Actual sequence: VBUS enabled immediately at boot → CC detection incomplete → USB 3.0 negotiation fails in one orientation

Hardware Analysis

• VBUS Control: GPIO 611 (USB_VBUS_EN)
• No dedicated CC logic chip: No HD3SS3220 or similar Type-C orientation detection chip found
• No I2C devices: i2cdetect shows no Type-C controllers
• No extcon/usb_role devices: System lacks standard Type-C detection framework

Observable Behavior

• Working orientation: Device appears on Bus 005 (SuperSpeed 5Gbps) ✅
• Failing orientation: Device appears on Bus 004 (High-speed 480Mbps) ❌
• Test device: Realtek RTL9210 USB NVMe adapter

Solutions Attempted

1. ✅ Shell Script - VERIFIED WORKING

File: /usr/local/bin/fix-usb-vbus.sh

#!/bin/bash
VBUS_GPIO=611

# Export and configure GPIO
echo $VBUS_GPIO > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio${VBUS_GPIO}/direction

# Disable VBUS
echo 0 > /sys/class/gpio/gpio${VBUS_GPIO}/value

# Wait for CC detection to stabilize (500ms)
sleep 0.5

# Re-enable VBUS
echo 1 > /sys/class/gpio/gpio${VBUS_GPIO}/value

Verification: Script works when run manually after boot, before inserting USB device.

2. ❌ Systemd Service - CAUSED BOOT FAILURE

Attempted to automate the script via systemd service at early boot stage - resulted in system unable to boot.

3. ❌ Device Tree Overlay - BROKE USB SUBSYSTEM

• Attempted using regulator-fixed with regulator-boot-off + startup delay
• Result: Lost Bus 004 and Bus 005 entirely; USB 3.0 controllers failed to initialize
• Why it failed: regulator-boot-off prevented USB controller enumeration during kernel init

4. Device Tree gpio-hog - NOT SUITABLE

• Would permanently hold GPIO 611 low
• No mechanism for delayed state change
• Would prevent VBUS from ever being enabled

Solution Comparison

Approach	Feasibility	Complexity	Status
Manual shell script	✅ Works	Low	Verified
Systemd service	❌ Boot failure	Low	Failed
Device tree overlay	❌ Too complex/conflicts	Medium	Not practical
Custom kernel driver	⚠️ Possible	High	Not attempted
Bootloader modification	⚠️ Theoretically possible	Very High	Not attempted

Key Technical Details

• GPIO number: 611 (confirmed via /sys/kernel/debug/gpio)
• Required delay: 500ms minimum for CC detection stabilization
• Bootloader: Raspberry Pi EEPROM bootloader (not U-Boot)
• USB controllers: xhci-hcd (Bus 004/005) and dwc3

Current Working Solution

Manual execution of fix-usb-vbus.sh script before inserting USB devices.

The script must be run after system boot but before USB device insertion to ensure proper USB 3.0 negotiation in both cable orientations.

Open Questions

1. How to automate the script without causing boot failure?
2. Is early bootloader-level GPIO control feasible with Raspberry Pi EEPROM?
3. Would a minimal kernel module be more reliable than systemd?

---

Date: January 24, 2026
Participant: Jiang
Hardware: Raspberry Pi CM5 Distiller system