Dear NVIDIA engineers,
We have encountered a problem, USB 3.1 devices are recognized as USB 2.0 devices. The device is AGX Orin with customized carrier board, and the software version is jetpack 6.2 Linux system.
The onboard USB interface, when plugged into a USB 3.1 device and turned on, is highly likely to be recognized as a USB 2.0 device rather than a USB 3.1 device.
When this error occurs once, executing the reboot command will result in the device being recognized as a USB 2.0 device each time. Is this a bug in SOM USB phy?
Thanks!
*** Please note that this reply is generated by LLM automatically ***
The issue you are experiencing with USB 3.1 devices being recognized as USB 2.0 devices on your customized Jetson AGX Orin carrier board with Jetpack 6.2 and Linux system is likely related to the USB PHY (Physical Layer) configuration.
The USB PHY is responsible for managing the physical layer of the USB interface, including the detection of the USB device speed (e.g., USB 2.0 or USB 3.1). The USB PHY image is a critical component in the USB stack, and any issues with it can lead to problems like the one you are experiencing.
There are a few possible explanations for this issue:
- USB PHY image version: The USB PHY image version you provided (image_1920759_502KB, image_720474_17KB, and image_1725975_846KB) might be outdated or incompatible with your customized carrier board. You can try updating the USB PHY image to the latest version available for your Jetson AGX Orin module.
- USB PHY configuration: The USB PHY configuration on your customized carrier board might not be set correctly, leading to the incorrect detection of USB 3.1 devices as USB 2.0 devices. You can try checking the USB PHY configuration on your carrier board and ensuring that it is set to support USB 3.1 speeds.
- Linux kernel configuration: The Linux kernel configuration on your Jetson AGX Orin module might not be set correctly to support USB 3.1 devices. You can try checking the Linux kernel configuration and ensuring that the USB 3.1 support is enabled.
- Hardware issue: There might be a hardware issue with your customized carrier board or the USB interface that is causing the problem. You can try checking the hardware design and ensuring that it is compatible with the Jetson AGX Orin module and the USB 3.1 standard.
To troubleshoot this issue, you can try the following steps:
- Update the USB PHY image: Update the USB PHY image to the latest version available for your Jetson AGX Orin module.
- Check the USB PHY configuration: Check the USB PHY configuration on your customized carrier board and ensure that it is set to support USB 3.1 speeds.
- Check the Linux kernel configuration: Check the Linux kernel configuration on your Jetson AGX Orin module and ensure that the USB 3.1 support is enabled.
- Run USB debugging tools: Run USB debugging tools, such as
usb-devices or usb-debug, to gather more information about the USB interface and the devices connected to it.
- Contact NVIDIA support: If none of the above steps resolve the issue, you can contact NVIDIA support for further assistance.
In comparison to other Jetson modules, the Jetson AGX Orin module has a similar USB architecture, but the USB PHY image and configuration might be different. Therefore, it is essential to ensure that the USB PHY image and configuration are correct and compatible with your customized carrier board.
In summary, the issue you are experiencing with USB 3.1 devices being recognized as USB 2.0 devices on your customized Jetson AGX Orin carrier board is likely related to the USB PHY configuration or image. You can try updating the USB PHY image, checking the USB PHY configuration, and ensuring that the Linux kernel configuration supports USB 3.1 devices. If none of these steps resolve the issue, you can contact NVIDIA support for further assistance.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
It must be declared that after the system startup is completed, inserting the USB 3.1 device can correctly identify it as a USB 3.1 device. The result of seeing lsUSB is that it is connected to bus 2 (USB 3.1 speed).
Some information which might or might not be useful to you…
Up until USB2 one controller handled legacy speeds plus the USB2. In the case of USB3 the controller is dedicated to USB3 only, and any issue requiring USB2 reroutes to a USB2 controller. Do your USB3 devices always show USB2? It sounds like maybe sometimes they do show up as USB3.
If devices sometimes work as USB3, then it implies the device tree is valid. It is more or less the device tree which makes different controllers capable of being found. If any specification in USB3 requirements fails, then it is possible the controller will revert to USB2 as a fallback mode.
One reason I suspect the device tree is correct is that you mentioned lsusb sees the device has USB3 capability. This tends to be from the USB3 wiring. Assuming this is correct, then using a USB2 controller would be for issues such as signal quality failure. However, there can be other reasons as well; an example is that USB3 provides more power to devices, and if the power cannot be delivered, then the system might revert back to USB2 and set a lower power delivery max.
I think most of the time, if the issue is not the device tree not setting up power and data correctly, then the most common issue is insufficient signal quality.
Thank you for the responses from linuxdev and WayneWWW.
We have no experience with this type of USB issue.
What should I do to determine if it is a USB signal quality issue?
You should review the document to modify device tree to match your board first.
Incidentally, the device tree is what tells the drivers which controllers to work with. This is part of the Bring-Up Guide. If that is correct, then you might look at the schematic for things like lane lengths and impedances. If this is correct, then the next step gets more difficult since it probably involves a USB3 hardware analyzer (basically looking at timings). It’s pretty common for someone to modify the carrier board but forget to change the device tree to point the drivers to the correct lane routing.
