4 USB 2.0, 2 USB3.2 ports NOT working on AGX Orin Industrial

Hi,

We have

  1. 2 USB 2.0 ports straight coming out from SOM module, even these 2 are not working, when we connect mouse or keyboard. Even power not coming in mouse or keyboard.

  2. There are 2 more USB 2.0 ports, which we have customized from PCIe lines to USB using a IC on our carrier board, even these 2 ports not working. BUT when we plug the mouse / keyboard, we see some USB device error messages appearing in the console. I am attaching he logs/snapshot for the same.

  1. We have 2 more USB 3.2 ports, which are brought out from UPHY0 lanes as per below configuration#2. We have modified ODMDATA accordingly, but even these are not working.

Please us know what might be the reason for this. The console+dmesg log is attached for reference.

console-log-dmesg-log_23-feb-2026.log (158.6 KB)

Thanks.strong text

1 Like

*** Please note that this reply is generated by LLM automatically ***

Based on the provided information, it appears that there are several issues with the USB ports on the Jetson AGX Orin module. Here’s a comprehensive analysis of the problem:

  1. Non-functional USB 2.0 ports: The two USB 2.0 ports directly connected to the SOM module are not working, and no power is being supplied to the connected devices (mouse or keyboard). This suggests a possible issue with the USB port configuration or the power supply to these ports.

  2. Non-functional customized USB 2.0 ports: The two customized USB 2.0 ports created from PCIe lines using an IC on the carrier board are also not working. This indicates that the issue might not be specific to the SOM module’s USB ports but could be related to the overall USB configuration or the IC used for customization.

  3. Non-functional USB 3.2 ports: The two USB 3.2 ports brought out from UPHY0 lanes, as per the provided configuration, are also not working. This suggests that the issue might be related to the UPHY lane configuration or the ODMDATA settings.

To troubleshoot the issue, consider the following steps:

  1. Verify UPHY lane configuration: Ensure that the UPHY lane configuration is correct and matches the provided configuration. Check the hsio-uphy-config-0 setting and verify that it is set to use the correct lanes for USB 3.2 ports.

  2. Check ODMDATA settings: Verify that the ODMDATA settings are correct and match the provided configuration. Ensure that the ODMDATA string includes the correct settings for USB 3.2 ports.

  3. Power supply: Check the power supply to the USB ports. Ensure that the power rails are correctly connected and that the voltage levels are within the specified range.

  4. IC configuration: If the customized USB 2.0 ports are not working, check the IC configuration and ensure that it is correctly set up to convert PCIe lines to USB.

  5. Kernel logs: Analyze the kernel logs (dmesg) to see if there are any error messages related to USB ports or UPHY lane configuration.

  6. Compare with known working configurations: Compare the current configuration with known working configurations to identify any differences or potential issues.

In summary, the issue appears to be related to the USB port configuration, UPHY lane configuration, or the IC used for customization. By verifying the UPHY lane configuration, ODMDATA settings, power supply, and IC configuration, you should be able to identify and resolve the issue.

Here’s a comparison of the provided configurations:

  • hsio-uphy-config-0 is used for USB 3.2 ports, which is correct.
  • gbe-uphy-config-22 is used for PCIe x1 (C1) and PCIe x4 (C4) ports, which is correct.
  • nvhs-uphy-config-1 is used for PCIe x4 (C4) port, which is correct.
  • hsio-uphy-config-40 is not used, which is correct since it restricts PCIe C1 RP to Gen2 speeds.

However, without more information about the specific IC used for customization and the exact configuration settings, it’s difficult to provide a more detailed analysis.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

If this is custom board, then you should provide backstory, for example, the schematic, device tree and other specific information.

There is no way to check your issue by just reading a log file.

BTW, if one USB port is from PCIe, then actually that is a PCIe device to us. We only gurarantee lspci would detect that. For the rest of items, please check with the PCIe device vendor.

  1. Pls find the schematics for your reference as shown below:

  1. Regarding device tree changes, I will go through the default code( 36.4.3) and see where I should modify to enable the 2 USB 2.0 ports which are connected through PCIe to USB Host controller. ( PI7C9XX440SL )

  2. Mean while, the other 2 USB 2.0 ports coming straight from the SOM module are not working.

  3. 2 USB 3.2 ports from UPHY0 lanes( configuration) I have overrided the ODMDATA in the jetson-agx-orin-devkit-insurtial.conf with choosing #configuration2 as shown below:
    Note: Here we are not using the PCIe x1 (C0), RP and left is blank from Lane 0 and using lane 1 and 2 for USb 3.2

Even these are not working.

Please let us know your inputs on this.

We can see it is getting detected in lspci. We need to modify the corresponding device tree entries right? If yes, I am looking in to the device tree code for this 2 USB 2.0 ports and see what needs to be changed.

We can see it is getting detected in lspci. We need to modify the corresponding device tree entries right? If yes, I am looking in to the device tree code for this 2 USB 2.0 ports and see what needs to be changed.

Actually no one knows the answer here. As I already told, this item is a PCIe solution from other vendors. Reading our document for device tree won’t help for your case..

Unless you are talking about even lspci is not detecting C0.

Now with some HW changes these 2 USB 2.0 ports are working fine as you told without any device tree changes as we have used a PCIe to USB 2.0 controller.

Sorry for the confusion.
This C0 is different, we not using it from the HW UPHY0(HSIO) lanes. But we are using only the 2 USB 3.2 ports ( P1 and P2) as shown in the below image.
However these USB 3.2 ports are not working even after ODMDATA override as explained in previous posts.


Now the other 2 USB 2.0 ports coming from the SOM modules directly are also not working. Any idea about this.

thanks for the support.

Where is your device tree content ?

  1. As i told earlier , 2 USB 2.0 ports(from PCIe to usb Host controller ) are working fine without any device tree changes.

  2. another set of 2 USB 2.0 ports coming directly from Jetson module not working.

  3. Another set of 2 USB 3.2 USB ports are also not working which are routed from UPHY0.

Hope this is clear. Thanks.

  1. another set of 2 USB 2.0 ports coming directly from Jetson module not working.
  2. Another set of 2 USB 3.2 USB ports are also not working which are routed from UPHY0.
    Hope this is clear. Thanks.

The only thing I see that seems to be clear here is a obvious mistake in your device tree.
If you are talking about you are just using device tree from NV devkit content, then that is wrong


Every custom board should have custom device tree. My point was I expected you already had did that. But it turns out nothing get changed there. Of course this thing won’t work.

These two usb 2.0 ports have been designed/routed same way as eval kit and as per reference design as per our hardware team.

That’s the reason we thought it’s same as default device tree code.

Let us know where our understanding is wrong here ..

So do you have type C PD controller in use on your board?

USB solution covers every setting in the device tree. Not just only 2 usb ports


Default setting has type C PD controller in the device tree. If that is not in use on any place of your board, then you need to modify device tree.

Please really take this as common sense when making a custom board. If you have even just one item that is different, then you need to update device tree..

No. Our hardware engineer did not explain this earlier, it was told its same as in evaluation kit.

Yes.
I saw and updated the device tree by commenting out the Type C controllers. Pls find the updated tegra234-p3737-0000+p3701-0000.dts file attached for your reference but still USB 2.0 ports not working. I have attached the decoded device tree from jetson AGX Orin Industrial also for your reference( I can see the changes I have done have got reflected )
running-device-tree-on-jetson-agx-orin.log (396.4 KB)

tegra234-p3737-0000+p3701-0000.log (10.7 KB)

I have conveyed the same to the hardware design person so that they can explain me the design clearly to make device tree changes.

Please let us know is there any thing wrong in this.
Thanks.

What is the dmesg after your DT modification?

jetson-dmesg-25-feb.log (72.6 KB)

Also one more doubt:
I see below code in the device tree:

  usb@3550000 {
  	status = "okay";

  	phys = <&{/bus@0/padctl@3520000/pads/usb2/lanes/usb2-0}>,
  	       <&{/bus@0/padctl@3520000/pads/usb3/lanes/usb3-1}>;
  	phy-names = "usb2-0", "usb3-0";
  };

  usb@3610000 {
  	status = "okay";

  	phys = <&{/bus@0/padctl@3520000/pads/usb2/lanes/usb2-0}>,
  	       <&{/bus@0/padctl@3520000/pads/usb2/lanes/usb2-1}>,
  	       <&{/bus@0/padctl@3520000/pads/usb2/lanes/usb2-2}>,
  	       <&{/bus@0/padctl@3520000/pads/usb2/lanes/usb2-3}>,
  	       <&{/bus@0/padctl@3520000/pads/usb3/lanes/usb3-0}>,
  	       <&{/bus@0/padctl@3520000/pads/usb3/lanes/usb3-1}>,
  	       <&{/bus@0/padctl@3520000/pads/usb3/lanes/usb3-2}>;
  	phy-names = "usb2-0", "usb2-1", "usb2-2", "usb2-3",
  		    "usb3-0", "usb3-1", "usb3-2";
  };

How to identify our USB address is usb@3550000 or usb@3610000? is it something to do with this.

One more observation: we see USB0, USB1 being listed when we execute ifconfig command, any idea why?

Pls let us know. Thanks.

Please refer to document first. If you are still asking the purpose of usb@3550000 and usb@3610000, then it seems you didn’t read or didn’t understand the document.

Your device tree is still wrong and it has this error.

[ 2.618932] phy phy-usb3.4: phy poweron failed → -19
[ 2.618935] tegra-xusb 3610000.usb: failed to enable PHYs: -19

Basically USB driver didn’t do anything there because above error. It just returned.

We went through the document, and with what best we can understand, we modified the device tree as per our requirement. but still the error is not going and USB ports not working.
Pls help/guide to fix the issue soon.

Dmesg and Updated device tree files are attached for reference.

tegra234-p3737-0000+p3701-0000-updated.txt (11.7 KB)

dmesg_28-feb.log (81.8 KB)

USB 2_0 ----> Used as companion with USB3_1 - Used for Type A USB port - (we removed Cypress controller entry in device tree )
USB2_1----> Used for Type A - USB port - (we removed Cypress controller entry in device tree )
USB_2_2 → Used for Type A - USB port
USB_2_3 → Used as companion with USB3_2 - Used for Type A USB port

USB_3_1----> Used for Type A - USB port
USB_3_2 → Used for Type A - USB port

Note: We have disabled USB_3_0 and USB_3_3 which we are not using

  1. We have used ODMData as per below configuration
    ( hsio-uphy-config-0 ). Is it fine

Thanks

[ 4.178403] phy phy-usb3.4: phy poweron failed → -19
[ 4.178406] tegra-xusb 3610000.usb: failed to enable PHYs: -19

Error is still there.

Please check your runtime device tree instead of what you shared.

runtime-27-feb.txt (396.4 KB)

I see following mistakes in the run time dts ( decoded from /proc/device-tree)

  1. Even though we had commented the usb3-0 node completely using /* */, we still see the USB2_companion is being set.

  1. Even though we have set usb3-0 status = “disabled”, we see that in the runtime dts, it is still set to “okay”

  1. Is this getting overridden some where else?? could you pls let us knw..

  2. Is anything wrong in our ODM data selection as hsio-uphy-config-0 ??

Thanks

@WayneWWW
Thanks for your support

tegra234-p3737-0000+p3701-0000-working-mouse.txt (10.7 KB)

Now with this updated device tree as attached abv, we observe that all 2 USB 2.0 ports and 2 USB 3.2 ports are working for mouse and keyboard.

  1. But, when we connect SSD it works only on USB 2.0 but it does not work on USB3.2 ports.
    Pls let us know what might be the reason.

Thanks.

You could just share the runtime DT and dmesg.

We actually don’t need the file you used from original dts as that file does not reveal the true status.

1 Like