Hi,
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.
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.
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?
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.
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.
Hi,
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.
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.
