Hi
I have designed a carrier board and connected UPHY11 + USB3 for use with USB 3.0 camera.
For unknown reason, it works only at USB2.0.
Is there a place in system boot log, which I can see why it is not working at USB 3 speed?
I’m attaching the diagram and the related schematic pages.
What do you see from “lsusb -t”? Does the root node show up as “5000M” speed? At what point in the tree does this diverge to “480M”?
Here’s the log from lsusb-t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 10000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=/0p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 1: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
I’m attaching the system diagram.
There’s a USB Hub with Mouse and Keyboard on it, connected to USB2 (“WIFI” in the diagram)
Note that the HUB going to the 10000M (10000M is USB3.1 gen. 2) “root_hub” is only capable of “USB3.1 gen. 1” (5000M is because that HUB was unable to run at 10000M even though the root_hub can run 10000M), and that nothing is attached to that root_hub other than the unused HUB.
The root_hub of everything else is itself set only for USB2 speed (480M). In that mode it is not possible to provide USB3 to anything downstream since upstream does not support this.
Someone else may be able to suggest ways to use the device tree to set the (currently) USB2 mode root_hub to USB3.1 gen. 1 mode, but this could depend on wiring as well.
I do not personally know if the particular wiring goes to the wrong controller, or if it is the device tree causing the wrong controller speed to be used. USB3 controllers usually reroute to a USB2 controller when detecting legacy standards…either the USB2 controller is the only one available due to wiring, or else the USB3 controller was never activated (associated) with that PHY. I cannot answer which this case is, but anyone answering will need to know which specific pins are being used from the module, and what device tree you are using for USB.
Thanks.
I want to divide this issue to h/w and s/w issues.
On the h/w side, I might consider placing USB Re-driver, for enhancing the high-speed signals.
Can I say that currently there’s no justification to do a new re-layout, and only if the ‘lsusb -t’ will show that the hub is capable to USB3.1, and the connected device will work at USB2.1 - then there might be a h/w issue - which should be solved by re-design.
As I understand, and please confirm/reject this, even if I’ll add a USB Re-Driver, and do a re-layout with best signal integrity handling, I’ll not be able to use USB3.1 on the ports which are now limited to 480M.
Can I say that the device tree should be fixed for having the two hubs capable to be USB3.1 gen 2, and two hubs capable of USB2.1 - as is in the diagram I’ve provided:
UPHY6 + USB1 used for one USB3.1 hub
UPHY11 + USB3 used for another USB3.1 hub
USB0 used for USB2.1 hub
USB2 also for usb2.1.
The device tree is “sort of” a hardware issue in that it tells the system where pins route. Any root_hub which is showing USB2 (480M) instead of USB3 (5000M) might be either because that controller has no possibility of supporting USB3, or it might simply be because the tree did not properly route and configure controllers. I have no idea which case this is.
In the case of a re-driver (bridge) chip, only you can say if signal quality is valid or not. Sometimes a USB3 device will fall back to USB2 (if and only if USB2 is also supported) if signal quality is insufficient. It is guaranteed that if the root_hub itself is only USB2 that no re-driver can run USB3 to that controller (there are “transaction translators”, or TT, which have the ability to adapt between two speeds, but the actual root_hub would still remain USB2…latency could be improved, and if multiple devices are on one bus, the bus would be better behaved…but that end device would never achieve beyond USB2 speeds). Until that controller is in USB3 mode you have no means to determine if a bridge chip is needed or not (unless you accept USB2 mode).
Someone from NVIDIA will need to confirm what the given ports are capable of and whether this is something which can be improved on via device tree (the adaptation guide explains this as well). To do so, anyone answering would need to know the current device tree and physical pin designations that the data wires connect to, along with which release (“head -n 1 /etc/nv_tegra_release”)…
Hi,
“Any root_hub which is showing USB2 (480M) instead of USB3 (5000M) might be either because that controller has no possibility of supporting USB3”
Can you please explain with examples, what might cause a controller not to support USB3?
Someone from NVIDIA will need to confirm what the given ports are capable of
and whether this is something which can be improved on via device tree
(the adaptation guide explains this as well).
To do so, anyone answering would need to know the current device tree
and physical pin designations that the data wires connect to,
along with which release (“head -n 1 /etc/nv_tegra_release”)…
I have attached the diagram and partial schematics to the first discussion.
I’m attaching now the connections to the SOM.
Kindly ask to review it and inform if this configuration and schematic can have two USB3 capable hubs.
SOM -USB-UPHY.pdf (98.1 KB)
Older controllers for USB2 also contain the logic for fallback cases of USB1.1 and USB1.0 (basically keyboards/mice/joysticks, but also some other audio devices). In the case of USB3 it is more common for the controller to have never had USB2 or other legacy speeds ever put into the silicon. In those cases a detection by the USB3 controller that something is requiring USB2 or earlier legacy speeds would result in a completely different controller being selected. If there is no configuration for finding that other controller, then the PHY will fail. Device trees will typically be used to pair USB3 and legacy controllers for legacy cases.
Thanks.
I’ll go back to dividing this issue to h/w and s/w issues.
On the hardware side:
I have sent the schematic, showing the connections from the SOM up to the USB ports.
Do you see anything that should be fixed to enable “USB3” operation (10000M) from the merge of USB11 (‘USB3 controller’)with USB3 (USB2 controller) into a USB-C connector.
On the Software side:
I’m not a s/w designer.
I assume that if the device tree is not matching the hardware, it will not create a 10000M hub, and in this case, there should be saying that there’s a USB Hub which uses UPHY11 and USB3.
Is there anything using UART3 debug port or any boot log file, which might inform on any issue which is causing the system to have the root hub to be defined as 480M, not 10000M?
(“/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M”)
Please inform which file(s) should be sent, and might help in solving this issue?
Thanks, Ishay
I couldn’t tell you about specific pins or controller addresses, but you are headed in the right direction. Someone familiar with custom design should be able to look at what you’ve provided, though perhaps with more questions on specific pin routing and with the device tree.
For device tree, assuming you can get in to the running system (e.g., via serial console or ssh), you could run this command (which in turn might require “sudo apt-get install device-tree-compiler”):
dtc -I fs -O dts -o extracted.txt /proc/device-tree
(I purposely extracted to a “.txt” name so the forum will accept it…this would be the other half of answering what needs to change)
You may just need to route your hardware to the other root_hub since not all of the HUBs support USB3. This is the part where I cannot help since I do not know the device tree address changes which would work, or if an actual wiring change would be needed.
Thanks.
I’m attaching the log of system boot, login and running the two commands specified above:
“sudo apt-get install device-tree-compiler”
“dtc -I fs -O dts -o extracted.txt /proc/device-tree”
teraterm_23Jan.log.txt (141 KB)
Rather than the log of the command running, what is required is the generated “extracted.txt” file.
Thanks.
I’m attaching the ‘extracted.txt’ file.
extracted.txt (354 KB)
“extracted.txt” should be enough now for someone knowing the specific USB requirements to be able to answer (a) if your wiring can run USB3, and (b) if so, then how your device tree relates. I do not know enough about the specific controllers/pins to answer this myself.
Hi,
UPHY11 is linked to USB/eSATA connector on Xavier developer kit. If it is a type-A port on your custom board, you should not need to modify device tree. Possibly you need to perform compliance test. Please check
https://developer.nvidia.com/embedded/dlc/agx-xavier-3-1-compliance-test-guide