Orin NX USB 3.0 only seems to be working on USB2.0 configuration

we made a custom Orin NX board which utilizes a USB 3.0 port, but whenever we plug in a dedicated usb 3.0 device this does not function properly.
By looking at dmesg output we see configuration errors with that specific port but it does look like it is correctly configured via the lsusb -t command.
we based our hw design around the “P3509-A01” design files, we removed the identifier EEPROM from this design though.

Our device tree buildup is based around the “sample rootfs” and "driver packages’ for version R.35.3.1 from the Nvidia developer downloads pages.
here we made the changes for the missing EEPROM accordingly.

Do we need to make additional changes for the use of USB 3.0 in the device tree or is included in the sample rootfs.

I added a screenshot from the terminal output for dmesg and lsusb -t commands as well as out HW design sheet for the USB connections.

Any help is appreciated.

Kind regards,

I can’t provide an answer, but I will mention something related that might be useful…

Originally, as USB evolved, a new chip was created each time a new USB generation was created. That single chip handled both the new standards and the legacy standards. So when USB 2 evolved, a single controller was capable of handling all of USB 1.0, 1.1, and 2.0. When SuperSpeed (USB 3) came along, this changed. There is now a separate USB 3 controller and a legacy controller (which handles USB 2 or older).

The wiring and software requires (A) detecting the USB generation being used, (B) the wiring to support both (a USB 3 socket/plug has more wires than legacy), and the logic to know to switch which controller the data routes to. It is this latter point which usually goes wrong in new carrier boards and changed device trees. Even if two carrier boards are basically the same, if the device tree does not properly tell the drivers how to route between the USB 2 and USB 3 controllers, then the one not routed correctly won’t work.

I can’t tell you how to find what is wrong in your case, but it would not be surprising if all root HUB USB modes show up, but one mode cannot be reached due to a device tree error.

I don’t know what does that mean based on P3509-A01 but showing up a USB C port in schematic.

3509 does not have type C…

Please refer to document and make software change to your device tree.


Hi Wayne,
Thank you for the quick reply.

We designed a carrier board for both the Xavier NX and Orin NX modules, so we based our HW design around the “P3509-A01” design files, we removed the USB hub (RTS5489-GR) and replaced the USB A connectors with a USB C connector.
Where in the P3509-A01 the USB data IO’s go through a USB hub to the Jeston module we removed the HUB and directly routed to those matching IO’s.

Do we need to make some changes to the device tree if we removed the USB hub or change the USB connector?

Removing usb hub ->probably no.

Change the usb connector → yes.

HI Wayne,

Ok, i didn’t expect that to be necessary since (i think) it’s only a different connector.
Can you explain where and why i need to the device tree.

Can that also explain that the USB connector is fully functional but limited to USB 2 speeds?

Do you have some background knowledge about device tree?

I don’t know where to start explain as this is common change when you change your hardware…

Hi Wayne,

I have very limited knowledge about it, we removed the EEPROM on our board and had to modify this according to the following settings:

Device tree records the hardware related software change.

For example, Orin NX can run on both p3509 board and also Orin Nano devkit carrier board…

But p3509 does not have type C port while Orin Nano devkit has it. The reason why it can run without issue is because when you flash Orin NX on p3509, one device tree binary (dtb) is in use… when you use Orin NX on Orin Nano carrier board, another device tree is in use…

Sorry to say that but if you don’t have knowledge about device tree, it would be hard for you to do this work.
Device tree is not something created by NVIDIA. It is common Linux kernel thing.

Better finding someone who is familiar with device tree to work with you.

That i understand.

But perhaps could you pinpoint me to the file where the usb ports are specified on my platform.
The device is flashed using the following command:

./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p “-c bootloader/t186ref/cfg/flash_t234_qspi.xml” --showlogs --network usb0 p3509-a02+p3767-0000 internal

And the matching EEPROM modify file is:

so i was hoping you could pinpoint me to the matching dts files for the USB connections.

I already shared the document in previous comment.

Sorry to say that what you are talking about is not even a device tree I am telling.

Could you file a new topic and directly ask how to modify a device tree? I mean a general question but not related to USB.

Ok, thank you for your time and support

You can go back to this topic after you know how to modify device tree. It is too early to do the usb modification…

You will definitely not understand what yourself is doing if we directly check the usb related change…

I don’t know if this is valid for your case, but I’ll give a somewhat general statement: It is quite common for a physical address to be associated with particular hardware and a particular driver. That hardware is not plug-n-play, and thus the driver won’t be able to associate with the hardware and won’t even know what the hardware is. A device tree very very often provides some sort of alias at a physical address, and names a driver to associate with that hardware. Think of this as a surrogate to what a plug-n-play device might provide. There are other parameters which might also be passed, e.g., if some feature is present or not, maybe a voltage or association with a particular power rail. I don’t know in your case, but there is extra wiring on USB 3 which is not present on USB 2, so you will need to somehow tell the USB 3 root HUB to associate with that wiring in a way which works with a USB 3 type-A connector.

Thanks for the reply.
The design we copied has a USB 3.0 A receptacle on it, we merely copied these IO’s and swapped to a different USB C connector on our design.
I dont understand how this would impact the linux side of it all as it can use the same IO’s and drivers.

Even changing the connector will lead to the driver change…

Your type C could even involve 3rdparty USB type C controller on it. To make it work, 3rdparty vendor even needs to provide their software patch.

Type C is typically a more complicated thing in software side than type A… Things are not that easy as your understanding…

I will emphasize what @WayneWWW just said: Detection and other details for routing to a type C connector is very different than a type-A connector. USB always has one end as device, and always has one end as host; however, type-C cables and other parts are sufficiently different than a type-A/type-B combination that you could say there is a bit of “Jedi mind trickery” used to know how to route the wiring. Substituting a USB 3 full-sized type-A with a USB3 micro-A could “just work”, but going between type-C and any other type needs much different setup.

1 Like

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