I’m experiencing issues with USB 3.0/3.2 ports on my Jetson AGX Thor Developer Kit and wanted to document the known problems and share workarounds for others who may be encountering similar issues.
Issue Summary
USB 3.0/3.2 devices are not being recognized or are inconsistently working on the Thor developer kit. This appears to be a widespread issue affecting multiple users.
Known Problems
Based on community reports and my own experience, here are the main USB 3 issues on Thor:
1. USB-C Port Recognition Issues (J81/J82)
J81 Port: The flash port has a known issue where OTG does not work. It’s currently set to device mode only due to a Cypress PD controller limitation.
J82 Port: Should support host mode, but some users report intermittent device recognition failures.
Symptom: USB devices plugged into USB-C ports are not detected in dmesg, even though the same devices work in USB-A ports, but USB-A does not detect as USB-3, 3.1, or 3.2.
2. Inconsistent Device Detection
USB 3 devices sometimes work on first boot but fail to reconnect after being unplugged and replugged
Devices may receive power but not show up in lsusb or system logs
Issue appears to worsen after system updates (e.g., after upgrading to r38.2)
3. Port Configuration Issues
USB-C ports may require specific power delivery configurations
Switching which port is used for power vs. data can sometimes resolve detection issues
Workarounds
Here are some workarounds that have helped other users:
Power Port Switching: If using J82 for power, try switching power to J81 instead, then use J82 for USB host devices. —- Does not work
Use USB-A Ports: When possible, use the USB-A ports instead of USB-C ports for better compatibility. – NO USB-3, 3.1, 3.2 Detection
Reboot After Connection: Some users report that rebooting with the USB device already connected improves recognition.
Check dmesg Logs: Run dmesg --follow and monitor for USB connection errors to diagnose specific issues.
Verify Kernel Version: Ensure you’re running the latest BSP (r38.4.2 or later) as some USB fixes have been included in recent updates.
Questions for NVIDIA/Community
Is there a timeline for a firmware/driver fix for the J81 OTG issue?
Are there known incompatibilities with specific USB 3.0/3.2 device types?
Will future JetPack releases include improved USB controller drivers?
Is there a recommended USB-C hub/adapter that works reliably with Thor?
My System Configuration
Device: Jetson AGX Thor Developer Kit
JetPack/BSP Version: 7.2
Kernel Version: (latest) output
Affected Ports: J81/J82 USB-C, USB-A
If you’re experiencing similar issues, please share your configuration and any additional workarounds you’ve discovered. Let’s help each other until NVIDIA releases an official fix.
the usb c (port) and the usb a ports do not allow for usb 3 3.1 or 3.2 either. i had claude opus working on it for hours. i like to think i know what im doing, been in the game like 25 years on and off, and the ai determined that there was a problem with the usb 3 controller.
even did a clean install from the sdk manager. no dice. ALSO, tried to register the sn, (bought it on amazon) and it said it was already registered. support gave me the run around on that too and was acting like they didnt want to do anything about it.
Im still troubleshooting. heres where we are atm. ill keep you updated
More importantly, a software update likely wouldn’t fix this USB issue because:
The XUSB firmware (SoC side) is already updated — we just applied the capsule, now running v90.05
The Realtek RTS5489/RTS0489 hub firmware is on the Realtek chip itself — factory-programmed, not part of the NVIDIA
BSP, and not user-updatable
The errors are on USB 2.0 bus 1 port 1-4.1 (behind the Realtek hub) — and you said nothing is plugged in, which
means the hub is generating phantom device connections
This points to a hardware issue with the Realtek hub or the physical USB-A port, not something fixable via software.
The repeated pattern of “detect device → fail to read descriptor → timeout → power cycle port → fail again → give up”
with nothing plugged in is characteristic of a faulty hub port or electrical noise on the signal lines.
Options to consider:
Ignore it — the errors are non-fatal and the system works fine otherwise. You could suppress the noise with a udev
rule or kernel parameter
Disable the specific port — use echo 0 > /sys/bus/usb/devices/1-4/1-4.1/authorized or similar to stop enumeration
attempts
Contact NVIDIA support — if the board is under warranty, this could be a defective Realtek hub chip
Check physically — is there any debris in the USB-A ports? The error is specifically on port 1 of the hub
Would you like me to disable that problematic port to stop the error spam, or investigate further?
I really don’t know what you are trying to tell but I think you should just reply our question first.
No one ever asked you to check those things you are checking now. And please be aware that I totally don’t know what you are trying to check there.
Too many items got skipped on your side and it seems you just don’t tell us.
For example, your first issue seems to be on type C but it seems you are talking about RTS5489 now. Which is obviously the type A items there and I have no idea why you are checking it.
Also, you didn’t post any log.
If you think that is hardware problem, at least share out the full kernel log for others to check first.
it turned out to be a software problem that was fixed with a full firmware capsule upgrade. if you re-read my first post carefully, usb-3 wasnt working on the usb-a ports and the jb2 usb-c port wasnt even providing power on the jb2 usb-c port. i fixed the usb-a ports usb-3 functionality already. i will post what the problem was and how it was fixed. working on jb2 usb-c now. it would be helpful if you could give me the complete device tree for the CYPD8225-i2c-usb-jb2/ and link to carrier board design documentation so i can manually configure it out to fix it. The CYPD8225 integration is
completely missing from the device tree.
And hardware board design items could be found here:
I just want to clarify this again.
Your comment basically skipped lots of items. I didn’t mean what you told is not correct or wrong.
What I would like to say is you may elaborate more about your points.
Basically what you are doing now is you speak to yourself and said there is a problem and then you fixed that problem. While I still don’t see any log to indicate the true problem you hit.
CYPD8225 problem could be related to the known issue on the OTG not work on type C port.
Also, basic rule in this forum. We expect you only report one issue in one topic. If you have multiple issues, file multiple topics.
What you are doing now seems to be trying to fix lots of things related to USB all in this topic. Which is not what we expect.
fair enough. my bad. I will post better in the future. and yes, the CYPD8225 problem is due to incomplete development on nvidia’s end. I found where the fix is scheduled for release q2 of this year, were not there yet. Here is the summary of how i fixed the usb 3 detection and use on the usb-a ports: The Realtek RTS5489 (USB 2.0) / RTS0489 (USB 3.0) hub on the carrier board was present, but USB
3.0 device enumeration was failing.
Suspected root cause: The XUSB controller firmware on the SoC was outdated. On Tegra platforms, the XUSB (Extensible
USB) controller requires matching firmware that is loaded from the bootloader partitions at boot time. If the firmware
version doesn’t match what the kernel/driver expects — or has bugs for the specific silicon revision — USB 3.0 link
training with downstream devices fails, even though USB 2.0 (which uses a simpler UTMI PHY rather than the UPHY
SuperSpeed lanes) continues to work.
The Realtek hub firmware (bcdDevice 1.97) is factory-programmed and not user-updatable, so it was ruled out. The fix
had to come from the SoC side.
The Fix: UEFI Capsule Bootloader Update
Generate Boot Update Payload (BUP)
From the JetPack 7.1 BSP on the WSL2 host:
cd ~/nvidia/nvidia_sdk/JetPack_7.1_Linux_JETSON_AGX_THOR_TARGETS/Linux_for_Tegra/
sudo ./l4t_generate_soc_bup.sh -e t26x_agx_bl_spec t26x
Generate UEFI Capsule from BUP
sudo ./l4t_generate_soc_capsule.sh
Output: TEGRA_BL.Cap (~21MB)
Transfer to Thor
scp TEGRA_BL.Cap kp@192.168.1.64:/opt/ota_package/
Apply Capsule on Thor
sudo nv_bootloader_capsule_updater.sh -q /opt/ota_package/TEGRA_BL.Cap
Reboot
sudo reboot
UEFI applied the capsule during reboot (progress 0%→100% visible on serial), then booted normally.
What Changed
┌────────────────┬───────────────────────────────┬──────────────────────────────────────────┐
│ │ Before │ After │
├────────────────┼───────────────────────────────┼──────────────────────────────────────────┤
│ XUSB firmware │ Outdated (shipped with board) │ v90.05 (2025-09-08) │
├────────────────┼───────────────────────────────┼──────────────────────────────────────────┤
│ Boot slot │ Slot A │ Slot B (capsule writes to inactive slot) │
├────────────────┼───────────────────────────────┼──────────────────────────────────────────┤
│ USB 3.0 │ Not working │ SuperSpeed 5Gbps confirmed │
├────────────────┼───────────────────────────────┼──────────────────────────────────────────┤
│ Capsule status │ 0 │ 1 │
└────────────────┴───────────────────────────────┴──────────────────────────────────────────┘
Verification
After reboot, a SanDisk USB 3.2 Gen1 flash drive plugged into USB-A port 2 enumerated at SuperSpeed 5Gbps — confirming
USB 3.0 link training was now succeeding through the Realtek USB 3.0 hub.
I would like to clarify this again. This whole discussion seems really to be in a strange direction.
First, your first post mentioned “JetPack/BSP Version: 7.2”. There is no Jetpack 7.2 released yet.. latest one is JP7.1 only. Thus, really don’t know what is the exact BSP you are using. Seems to be something even older.
Second, it seems you did an update that was already released from us. That is not called a fix but just a software update.
This is back to what I said in the beginning that this is not a RMA scope… you did a software update and then the issue fixed…
I would say you could just post symptoms/logs/Jetpack version in very brief way next time to save your time…
There are still lots of weird posts here
In above link, you mentioned you did sdkmanager installation. However, if that is true, then your system should be already in Jetpack7.1 so you actually no need to do capsule update…
That could be 2 possible reasons here:
You didn’t update JP7.1 to your board at all. You chose a old version.
You actually chose JP7.1 but your flash didn’t succeed.
During the capsule update im pretty sure claude opus also did a firmware update for the XUSB firmware to v90.05 (2025-09-08) that does not happen with a sdk manager clean install. Thats my only explanation. Claude opus 4.6 did it for me over serial connection… I dont know if there was some secret sauce it did in addition thats not standard in a sdk manager clean install. Your right though, it turned out to not be a rma issue. thanks for your patience. Also…. clearly yall have released 7.2. heres your proof. its interesting though, when the thor was new i set it up using the usb thumb drive method with 7.1 and everything worked as it should. it makes me wonder if 7.2 has an issue that required me to do the firmware update. Also, when doing a clean install with sdk manager, your right, it only lists 7.1, but it installs 7.2. im just thinking out loud though. Anyways, you can close the thread. Thanks for your time.
Man you got me . Actually, now that i think about it, after i did the clean install jtop wasnt working so i set claude-code to fixing it. Thats where it may have come from then. I stand corrected. Anyways, thanks for alll your help. Since this thread seems to be a nothing-burger feel free to get rid of it so the rest of the community doesnt get confused. My appologies. ill be better in the future if i have to get on here for anything.
