Xavier NX USB 3.0 devices are recognized as USB 2.0


we have a custom Xavier NX board and some problems with a USB 3.0 port.

Devices plugged in into that port are recognized as USB 2.0 devices only.
The port itself seems to be okay and lsusb reports 10000M for this port.

Output form lsusb -t :

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 10000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/7p, 480M
|__ Port 1: Dev 4, If 2, Class=Miscellaneous Device, Driver=, 480M
|__ Port 1: Dev 4, If 0, Class=Miscellaneous Device, Driver=, 480M
|__ Port 1: Dev 4, If 1, Class=Miscellaneous Device, Driver=, 480M
|__ Port 5: Dev 3, If 0, Class=Communications, Driver=cdc_ether, 480M
|__ Port 5: Dev 3, If 1, Class=CDC Data, Driver=cdc_ether, 480M

The device on port 1 is reported with 480M, but should be USB 3.0 super speed.

I’ve attached the dmesg log and our device tree.
tegra194-brma3n-nx.dts (272.2 KB)
dmesg_usb_yocto_debug.log (101.5 KB)

Does anybody has an idea how to fix this?

For custom board, you have to do USB compliance test. Please check tuning guide in download center.

One issue I think is worth emphasizing is that even if all wiring and software is correct, but there is some issue with signal quality (which could be as simple as trace layout), then a proper USB3 device will be throttled back to USB2 speeds (some USB3 devices don’t have a slower mode, e.g., some cameras, and so those would disappear entirely). It would be difficult to know if there is more involved with the issue unless that compliance test succeeds. If you have confidence that signal quality is not the issue, then it is possible to be sure the problem is something else.

Thanks a lot for your responses.
We’re using the following board from Syslogic AI Embedded PC RS A3N. Since we haven’t designed the board I am not sure how to do the USB 3.1 compliance testing.

In my first post I didn’t mention that USB 3.0 is working with Jetpack 4.6 on this board. We started building a custom image with yocto using the device tree from the Jetpack image and run into the problem with the USB 3.0 interface.

Assuming that board has good signal quality (and it looks like a finished product, so benefit of the doubt), then I have to consider software. I see one of the logs is for Yocto. I also noticed that the vendor has available the NVIDIA L4T (Ubuntu 18.04) in their official list of software. My next “most likely” culprit on the list is that this lacks the correct NVIDIA drivers. Typically there is a requirement for the proper software support when it comes to NVIDIA-specific hardware, and I don’t know if that would be the case with the USB3, but possibly it is. Is this a custom install and not the NVIDIA Ubuntu?

Yes you’re right, we’re using Yocto to build or own image. This image is based on NVIDIA L4T R32.6.1 with JetPack 4.6 from Github: OE4T/meta-tegra.

I don’t think that it lacks of the correct NVIDIA drivers. If I run lshw there are 2 different USB xHCI host controllers. The first one has usb-2.00 capability and the second one has usb-3.10 capability:

       product: xHCI Host Controller
       vendor: Linux 4.9.253-l4t-r32.6+g3fa334c5ca49 xhci-hcd
       physical id: 1
       bus info: usb@1
       logical name: usb1
       version: 4.09
       capabilities: usb-2.00
       configuration: driver=hub slots=4 speed=480Mbit/s
          description: USB hub
          product: Hub
          vendor: Standard Microsystems Corp.
          physical id: 3
          bus info: usb@1:3
          version: 0.02
          capabilities: usb-2.00
          configuration: driver=hub maxpower=2mA slots=7 speed=480Mbit/s
       product: xHCI Host Controller
       vendor: Linux 4.9.253-l4t-r32.6+g3fa334c5ca49 xhci-hcd
       physical id: 2
       bus info: usb@2
       logical name: usb2
       version: 4.09
       capabilities: usb-3.10
       configuration: driver=hub slots=4 speed=10000Mbit/s

But lshw also shows that one of the PCI bridges has been configured with driver=nvme. So I am wondering if this configuration could be the root cause for my problem?

          description: PCI bridge
          product: NVIDIA Corporation
          vendor: NVIDIA Corporation
          physical id: 101
          bus info: pci@0005:00:00.0
          version: a1
          width: 32 bits
          clock: 33MHz
          capabilities: pci pm msi pciexpress msix normal_decode bus_master cap_list
          configuration: driver=pcieport
          resources: irq:35 memory:1f40000000-1f400fffff
             description: Non-Volatile memory controller
             physical id: 0
             bus info: pci@0005:01:00.0
             version: 01
             width: 64 bits
             clock: 33MHz
             capabilities: storage pm msi pciexpress msix nvm_express bus_master cap_list
             configuration: driver=nvme latency=0
             resources: irq:35 memory:1f40000000-1f40003fff

I don’t know what the correct driver would be what is actually found or not. I would consider it possible that a driver is present, but that it is the wrong driver. Does this use the NVIDIA kernel source? If it is mainline, then it is unlikely to be correct even if it works. I’m not sure how to decide if it is the right driver (having a driver show as present is good, but it is possible a different driver than the expected driver is what is found).

Is it possible to find out if the NVIDIA Ubuntu works? You could in theory clone the existing system to save whatever is there, and then flash with the NVIDIA Ubuntu, test, and then flash the clone to put the old rootfs back in place. One important detail though is that other than the rootfs all other content related to boot might differ, so a clone would not necessarily be a perfect copy of the whole system (only rootfs would be guaranteed as a perfect copy).

Finally we fixed this issue. The root cause was a wrong PINMUX_CONFIG. Due to a typo in our yocto build path we used the default nvidia configuration where USB3 has been enabled on internal mPCIe interface. But for the custom board from syslogic we’re needing a different configuration to enable front USB3 connector.

Thanks for you help :)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.