AGX Orin R39.2.1: J40 USB-C falls back to USB2 at boot and fails after replug

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
, ,
1

Title

Jetson AGX Orin Developer Kit R39.2.1: J40 Type-C falls back to USB 2.0 when RealSense D435i is connected before boot, then fails to re-enumerate after unplug/replug

Hardware

  • NVIDIA Jetson AGX Orin Developer Kit 64GB

  • Intel RealSense D435i RGB-D camera

  • Camera connected directly to the J40 USB Type-C port, near the 40-pin header

  • The same camera and USB-C cable work normally on the other Type-C port / fixed-host USB port

Software Environment

Jetson Linux / L4T:
# R39 (release), REVISION: 2.1, GCID: 46758480
BOARD: generic
DATE: Fri Aug 7 05:54:22 AM UTC 2026

Kernel:
Linux 6.8.12-1021-tegra
#1 SMP PREEMPT Thu Aug 6 21:56:04 PDT 2026
aarch64 GNU/Linux

BIOS:
39.2.1-gcid-46758480

Relevant NVIDIA packages are also all from the same R39.2.1 release:

nvidia-l4t-bootloader      39.2.1-20260806224157
nvidia-l4t-core            39.2.1-20260806224157
nvidia-l4t-kernel          6.8.12-tegra-39.2.1-20260806224157
nvidia-l4t-kernel-dtbs     6.8.12-tegra-39.2.1-20260806224157
nvidia-l4t-kernel-oot-modules
                           6.8.12-tegra-39.2.1-20260806224157

Therefore, the BIOS, bootloader, rootfs, kernel, and DTB appear to be aligned to R39.2.1.

Problem Description

I found a consistent behavior depending on whether the RealSense D435i is already connected to J40 when the Jetson boots.

Case 1: Camera is NOT connected during boot

  1. Boot the Jetson without the D435i connected to J40.

  2. Wait until Linux has fully booted.

  3. Connect the D435i to J40.

Result:

  • The D435i is correctly detected as USB 3.x SuperSpeed.

  • dmesg reports:

usb 2-2: new SuperSpeed USB device using tegra-xusb
usb 2-2: New USB device found, idVendor=8086, idProduct=0b3a
usb 2-2: Product: Intel(R) RealSense(TM) Depth Camera 435i

  • Hot-unplug and hot-plug continue to work normally afterward.

  • The camera continues to enumerate as USB 3.x.

This behavior is stable.

Case 2: Camera IS connected to J40 before power-on

  1. Power off the Jetson.

  2. Connect the D435i to J40.

  3. Power on the Jetson.

  4. Wait for Linux to boot.

Result:

The D435i is detected only as USB 2.0 / 480 Mbps.

lsusb -t:

/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=tegra-xusb/4p, 480M
    |__ Port 001: Dev 004, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 001: Dev 004, If 1, Class=Video, Driver=uvcvideo, 480M
    |__ Port 001: Dev 004, If 2, Class=Video, Driver=uvcvideo, 480M
    |__ Port 001: Dev 004, If 3, Class=Video, Driver=uvcvideo, 480M
    |__ Port 001: Dev 004, If 4, Class=Video, Driver=uvcvideo, 480M
    |__ Port 001: Dev 004, If 5, Class=Human Interface Device, Driver=usbhid, 480M

The camera is present:

Bus 001 Device 004: ID 8086:0b3a Intel Corp. Intel(R) RealSense(TM) Depth Camera 435i

The kernel log confirms that the camera enumerates only as USB 2.0 High-Speed:

usb 1-1: new high-speed USB device number 4 using tegra-xusb

usb 1-1: New USB device found, idVendor=8086, idProduct=0b3a
usb 1-1: Product: Intel(R) RealSense(TM) Depth Camera 435i
usb 1-1: Manufacturer: Intel(R) RealSense(TM) Depth Camera 435i

However, the USB 3.x root hub itself is operating normally:

/:  Bus 002.Port 001: Dev 001, Class=root_hub,
    Driver=tegra-xusb/4p, 10000M

Another USB 3 hub on the same system is also successfully operating at 10 Gbps:

|__ Port 003: Dev 002, Class=Hub, Driver=hub/4p, 10000M

The boot log also shows:

tegra-xusb 3610000.usb: Host supports USB 3.1 Enhanced SuperSpeed

usb 2-3: new SuperSpeed Plus Gen 2x1 USB device number 2 using tegra-xusb

Therefore, the overall Tegra xHCI USB 3 controller appears to be functional during the problematic boot.

Additional Important Behavior

After booting in the bad state described above:

  1. The D435i is initially detected as USB 2.0 / 480M.

  2. I unplug the D435i from J40.

The kernel correctly reports:

usb 1-1: USB disconnect, device number 4
  1. I reconnect the camera to J40.

At this point, the camera is not detected at all.

There is:

  • no new high-speed USB device

  • no new SuperSpeed USB device

  • no new USB enumeration message in dmesg

lsusb -t no longer shows the RealSense device.

However, the Type-C subsystem clearly detects that something has been reconnected.

After reconnecting the camera:

===== port1 =====
data_role: [host]
power_role: [source]
partner: YES

So J40 appears to have:

  • detected a Type-C partner

  • entered host data role

  • entered source power role

but the USB device is never passed through to the xHCI USB bus.

Before reconnecting, partner becomes NO, and after reconnecting it returns to YES.

Type-C / USB Role Observation

The J40-related Type-C port shows:

port1:
data_role: host
power_role: source
partner: YES

even in the state where the RealSense camera cannot be enumerated by USB.

This suggests that Type-C CC/partner detection and VBUS sourcing are working, while the actual USB data path is not being re-established.

Reproducibility

The behavior is strongly correlated with boot state:

Camera disconnected during boot
→ boot Linux
→ connect D435i to J40
→ USB 3 SuperSpeed works
→ later hot-plug also works

Camera already connected to J40 before boot
→ boot Linux
→ D435i enumerates as USB 2.0 / 480M
→ unplug D435i
→ reconnect D435i
→ Type-C partner is detected
→ no USB enumeration occurs

I can reproduce this behavior consistently.

Comparison With the Other Type-C Port

The same D435i and cable can operate as USB 3.x when connected to the other Type-C / fixed-host port.

Therefore, the camera and cable are capable of USB 3 operation.

The issue appears specific to J40 and its dual-role Type-C/OTG behavior.

Potentially Relevant Boot Messages

During boot I see dependency-cycle messages involving J40’s Type-C connector and USB PHYs:

/bus@0/padctl@3520000/ports/usb2-0:
Fixed dependency cycle(s) with
/bus@0/i2c@c240000/typec@8/connector@1

/bus@0/padctl@3520000/ports/usb3-1:
Fixed dependency cycle(s) with
/bus@0/i2c@c240000/typec@8/connector@1

/bus@0/i2c@c240000/typec@8/connector@1:
Fixed dependency cycle(s) with
/bus@0/padctl@3520000/ports/usb3-1

I understand that these messages do not necessarily indicate an error by themselves, but I am including them because the affected port appears to correspond to connector@1, usb2-0, and usb3-1.

My Current Interpretation

It appears that when a USB 3 device is already connected to J40 during boot:

  • the USB 2 companion path initializes successfully,

  • the D435i falls back to USB 2 High-Speed,

  • the J40 SuperSpeed path may not be initialized or routed correctly,

  • after a subsequent detach/attach, the Type-C controller continues to detect the partner and reports host + source,

  • but the USB host controller receives no new USB enumeration event.

This makes me suspect a boot-time initialization or synchronization issue involving the J40 dual-role Type-C path, potentially around:

  • the USB 3 usb3-1 PHY,

  • Type-C SuperSpeed mux/switch state,

  • USB role-switch state,

  • UCSI / Type-C controller initialization,

  • or the handoff between firmware/bootloader and the Linux Tegra XUSB driver.

I do not yet know which component is responsible.

Expected Behavior

If a USB 3 camera is connected to J40 before boot, I would expect it to enumerate as USB 3.x after Linux starts, in the same way as when it is connected after boot.

Additionally, unplugging and reconnecting the camera should allow it to enumerate again without rebooting the Jetson.

Questions for NVIDIA

  1. Is this a known issue in Jetson Linux R39.2.1 / JetPack 7.2.1 with the J40 dual-role Type-C port?

  2. Is there a known issue with J40 usb3-1 initialization when a USB 3 device is already attached before boot?

  3. Is there a recommended way to reset only the J40 USB role / PHY / Type-C mux after Linux has booted, without resetting the entire 3610000.usb xHCI controller?

  4. Are there any debugfs, tracepoints, UCSI logs, or Tegra XUSB diagnostics that NVIDIA would recommend collecting to determine whether the failure occurs in the Type-C controller, role switch, SuperSpeed mux, or UPHY?

  5. Is there a device-tree or kernel workaround available for forcing J40 to operate as a fixed USB host if device/OTG functionality is not required?

I can provide complete good-boot and bad-boot dmesg logs if needed.

AGX Orin J40 USB port always recognized as USB2.0