USB0 port not exposing SuperSpeed (USB3) lane on custom Orin NX carrier board — UVC camera fails on USB0, works on USB1

Hi,**

Board:** Custom carrier board based on Jetson Orin NX (p3767 module)
L4T / JetPack version: L4T 36.5

Description:

I have a custom carrier board derived from the Orin NX reference design, with the padctl@3520000 USB port configuration below (from my board dts)

ports {
/* recovery port */
usb2-0 {
mode = “otg”;
vbus-supply = <&vdd_5v0_sys>;
status = “okay”;
usb-role-switch;
};

/* hub */
usb2-1 {
    mode = "host";
    vbus-supply = <&vdd_5v0_sys>; (I changed the default to 5v as respect to my schematic)
    status = "okay";
};

/* M.2 Key-E */
usb2-2 {
    mode = "host";
    vbus-supply = <&vdd_5v0_sys>;
    status = "okay";
};

/* hub */
usb3-0 {
    nvidia,usb2-companion = <1>;
    status = "okay";
};

/* J5 */
usb3-1 {
    nvidia,usb2-companion = <0>;
    status = "okay";
};

};

I’m testing the same USB3.0 UVC camera (Cypress FX3-based, composite UVC+CDC device) on two physical ports on my carrier board, referred to as USB0 and USB1:

  • USB1 — camera works correctly, enumerates at SuperSpeed.

  • USB0 — camera enumerates only at USB2 High-Speed (480M), through an onboard 4-port USB hub, and the uvcvideo driver fails to bind. No /dev/videoX node is created.

    USB1 (working) — lsusb -t:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 10000M
        |__ Port 2: Dev 2, If 2, Class=Video, Driver=uvcvideo, 5000M
        |__ Port 2: Dev 2, If 3, Class=Video, Driver=uvcvideo, 5000M
        (plus CDC ACM interfaces on same device)
    /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M
        |__ Port 1: Dev 10, Hub/4p, 480M
        |__ Port 2: Dev 3, Hub/4p, 480M
            |__ Port 4: Dev 7, HID
        |__ Port 3: Dev 2, Wireless (bt)
    

    USB0 (failing) — 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 1: Dev 10, Hub/4p, 480M
        |__ Port 2: Dev 3, Hub/4p, 480M
            |__ Port 4: Dev 7, HID
            |__ Port 3: Dev 11, If 0, Class=Video, Driver=, 480M
            |__ Port 3: Dev 11, If 1, Class=Video, Driver=, 480M
        |__ Port 3: Dev 2, Wireless (bt)
    

dmesg on USB0 failure:

[  790.881108] usb 1-2.2: new high-speed USB device number 30 using tegra-xusb
[  791.248667] usb 1-2.2: Found UVC 1.10 device FX3 CAMERA (04b4:0040)
[  791.249339] usb 1-2.2: Failed to query (GET_INFO) UVC control 2 on unit 2: -32 (exp. 1).
...
[  791.257719] usb 1-2.2: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
[  791.258238] uvcvideo 1-2.2:1.1: Failed to query (129) UVC probe control : -32 (exp. 34).
[  791.258242] uvcvideo 1-2.2:1.1: Failed to initialize the device (-5).

Key observation: On USB0, Bus 02 (the 10000M SuperSpeed root hub) shows no device at all — the camera only ever appears on Bus 01 (USB2-only), behind the onboard hub. On USB1, the same camera enumerates directly on Bus 02 at 5000M with no issues.

My understanding so far: Based on the DT, USB1 likely maps to the usb2-0/usb3-1 direct-wired pad pair, while USB0 maps to usb2-1/usb3-0, which is directly given to 5v(usb Host). I am getting the error when i connect the hub(at USB2.0 Port) where its composite UVC+CDC descriptors fail UVC probe/commit negotiation (-32/EPIPE) rather than functioning as intended over USB3. If I connect to USB3 port in External USB-HUB connected by Type-A. I did not get any message in dmesg too.

Questions:

  1. Is nvidia,usb2-companion sufficient by itself to enable SuperSpeed forwarding through an onboard hub wired to a usb3-x pad, or are there additional DT/pinmux/padctl requirements (e.g., pad calibration parameters, nvidia,lanes, or hs-usb-pad type settings) needed for hub-connected SS ports specifically?
  2. Are there recommended debugfs/sysfs nodes to check whether the usb3-0 XUSB pad is actually being trained/linked (link training status, LFPS detection, etc.) so I can distinguish a hardware/layout issue (hub or trace not carrying SS) from a DT/pad configuration issue?
  3. Is there a known limitation with routing SuperSpeed through this class of onboard hub on Orin NX, or a recommended reference schematic for this pad pairing that I should cross-check my carrier board layout against?

Any guidance on diagnosing whether this is a hub-hardware limitation vs. a padctl/DT misconfiguration would be greatly appreciated.

Please help me to understand the issue.

Thanks.

Regards,
Kamalesh

Could you check if rel-36.4.4 gives you a working one even with same device tree setting?

We notice rel-36.5 seems having an issue with OTG cap USB port that will be stuck in usb2 speed.

Hi,

Just to confirm — my failing port (USB0) is the fixed host-mode port (usb2-1/usb3-0, routed through direct to SOM), not the OTG-capable port (usb2-0/usb3-1, which is our working USB1/J5 port). Does the rel-36.5 regression you mentioned affect the companion USB3 pad of an OTG port as well, or only the OTG port itself?

Regards,
Kamalesh

Hi,

Update:

We tried with the L4T 36.4.4 image as well, using the same device tree configuration. The connector under test is USB-A, mapped to usb3-0 with usb2-1 companion.

After connecting the camera via the USB 3.0 cable, we did not get any message in the kernel dmesg log at all — not even the USB2 enumeration messages like rel-36.5.

Could you help us understand why the device isn’t being detected at all, and whether there’s an additional step needed (e.g., a different DT change) when testing?

Thank you.

Regards,
Kamalesh

If that is a pure host port, then that case is more simple

Please check if vbus is giving out power to the USB device first. That is the most common problem when dmesg totally didn’t not give you any message.

Also, check your runtime DT under /proc/device-tree if it is really what you expect to run.

Hi,

Update:

The camera interface board we are using has its own separate power supply; it is not bus-powered from the host VBUS.

We tested with the usb3-1/usb2-0 port combination (J5) on our board, and we are able to get video output correctly with this camera board.

However, on usb3-0/usb2-1 (USB-A, hub-routed port), we are not getting any video, and as shared earlier, we do not see any device-connect messages in dmesg at all on this port.

We have checked the VBUS supply and it is giving 5V. We also checked under /proc/device-tree/, and usb3-0 shows as companion to usb2-1 only, as expected. The VBUS-supply setting registers for usb2-1 and usb2-0 both read 0xf7.

Regulator summary attached below for reference:

regulator                      use open bypass  opmode voltage current     min     max
regulator-dummy                  1    0      0 unknown     0mV     0mA     0mV     0mV
VDD_5V0_SYS                      7    6      0 unknown  5000mV     0mA  5000mV  5000mV
usb2-2-vbus                      1                                 0mA     0mV     0mV
usb2-1-vbus                      1                                 0mA     0mV     0mV
usb2-0-vbus                      1                                 0mA     0mV     0mV
VDD_1V8_AO                       5    5      0 unknown  1800mV     0mA  1800mV  1800mV
140a0000.pcie-vddio-pex-ctl      1                                 0mA     0mV     0mV
141e0000.pcie-vddio-pex-ctl      0                                 0mA     0mV     0mV
14160000.pcie-vddio-pex-ctl      1                                 0mA     0mV     0mV
14100000.pcie-vddio-pex-ctl      1                                 0mA     0mV     0mV
3520000.padctl-vclamp-usb        1                                 0mA     0mV     0mV
VDD_3V3_AO                       2    1      0 unknown 33000mV     0mA 33000mV 33000mV
3520000.padctl-avdd-usb          1                                 0mA     0mV     0mV
VDD_AV10_HUB                     1    0      0 unknown  1100mV     0mA  1100mV  1100mV
VDD_1V8_HS                       1    1      0 unknown  1800mV     0mA  1800mV  1800mV
0-0050-vcc                       0                                 0mA     0mV     0mV
VDD_1V8_SYS                      1    1      0 unknown  1800mV     0mA  1800mV  1800mV
0-0057-vcc                       0                                 0mA     0mV     0mV
VDD-3V3-SYS                      1    0      0 unknown  3300mV     0mA  3300mV  3300mV
VDD_3V3_PCIE                     1    1      0 unknown  3300mV     0mA  3300mV  3300mV
140a0000.pcie-vpcie3v3           1                                 0mA     0mV     0mV
VDD_3V3_SD                       0    0      0 unknown  3300mV     0mA  3300mV  3300mV

Please let us know your thoughts.

Regards,
Kamalesh

Hi,

Below states my device tree current configuration. Is this correct or any confliction configuration are present?





padctl@3520000 {
	status = "okay";

	pads {
		usb2 {
			lanes {
				usb2-0 {
					nvidia,function = "xusb";
					status = "okay";
				};

				usb2-1 {
					nvidia,function = "xusb";
                                                vbus-supply = <&vdd_5v0_sys>;
					status = "okay";
				};

				usb2-2 {
					nvidia,function = "xusb";
					status = "okay";
				};
			};
		};

		usb3 {
			lanes {
				usb3-0 {
					nvidia,function = "xusb";
					status = "okay";
				};

				usb3-1 {
					nvidia,function = "xusb";
					status = "okay";
				};
			};
		};
	};

	ports {
		/\* recovery port \*/
		usb2-0 {
			mode = "otg";
			vbus-supply = <&vdd_5v0_sys>;
			status = "okay";
			usb-role-switch;
		};

		/\* hub \*/
		usb2-1 {
			mode = "host";
			vbus-supply = <&vdd_5v0_sys>;
			status = "okay";
		};

		/\* M.2 Key-E \*/
		usb2-2 {
			mode = "host";
			vbus-supply = <&vdd_5v0_sys>;
			status = "okay";
		};

		/\* hub \*/
		usb3-0 {
			nvidia,usb2-companion = <1>;

			status = "okay";
		};

		/\* J5 \*/
		usb3-1 {
			nvidia,usb2-companion = <0>;
			status = "okay";
		};
	};
};

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-1";
};

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/usb3/lanes/usb3-0}>,
	       <&{/bus@0/padctl@3520000/pads/usb3/lanes/usb3-1}>;
	phy-names = "usb2-0", "usb2-1", "usb2-2", "usb3-0",
		    "usb3-1";
};

Looking forward to your inputs.
Thanks.

Regards,
Kamalesh

Since USB1 works and USB0 does not, the hardware path and SOM pads are likely fine; the issue is in the USB3 companion mapping or padmux for the hub port.

Check these things in your DTS:

1. usb3-0 companion. Your snippet shows nvidia,usb2-companion = <1> for usb3-0. Verify the numeric companion matches the XUSB pad number of usb2-1, not the logical port index. On Orin NX the mapping is easy to invert.

2. pinctrl reset state. Make sure the USB3 SS lanes are not left in a quiescent or SATA/PCIe mux setting. Compare the pinmux spreadsheet output against the generated pinmux.dtsi.

3. Lane ownership. If usb3-0 shares a SS lane with another interface (for example the M.2 Key-E or NVMe), only one can own it at boot.

4. L4T 36.5 regression. There is a known issue where OTG-capable ports can enumerate at USB2 only. Even though your failing port is fixed-host, the USB3 companion pad may still be affected if it is part of the same OTG-capable controller group. Testing 36.4.4 is the fastest way to confirm this.

Diagnostic commands:

- lsusb -t to see if the camera attaches as 480M or 5000M.

- cat /sys/kernel/debug/usb/xhci_reg/* (if enabled) to inspect XUSB port status.

- diff your generated pinmux.dtsi against the Jetson Orin NX DevKit pinmux for the USB3 SS pins.

If 36.4.4 works with identical DTS, it is almost certainly the L4T 36.5 regression and you should track the JetPack release notes for the fix or backport.

Hi,

Thank you for the detailed checklist. Here are our findings on each point:

  1. Companion index — This is not inverted. usb2-1’s pad number is 1, as attached earlier, and it correctly matches nvidia,usb2-companion = <1> for usb3-0.
  2. Pinmux — We checked the pinmux configuration, and it is correctly set for the USB3 SS lanes; no mismatch found against the generated pinmux.dtsi.
  3. Lane ownership — The SS lane for usb3-0 is dedicated/owned only by this USB3 port; it is not shared with any other interface (M.2 Key-E/NVMe or otherwise).
  4. L4T 36.5 regression — We also tried with 36.4.4, and got the same result (no enumeration, no dmesg messages).

Please let us know your thoughts on the next steps.

Regards,
Kamalesh

Thanks for running through the checklist systematically. If companion index, pinmux, lane ownership, and the L4T 36.5 regression are all ruled out, then “no dmesg at all” points to a board-level signal or power problem rather than a device-tree issue.

Next things to check, in order:

1. USB2 D+/D- connectivity to the SOM. If the camera works on usb3-1/usb2-0 but nothing appears on usb3-0/usb2-1, verify the D+/D- pair for usb2-1 actually reaches the USB-A connector with the correct polarity. A swapped or open pair will cause complete silence in dmesg.

2. VBUS sensing, not just VBUS presence. The xHCI controller needs the ID/VBUS detect line to assert host mode. If your carrier uses a load switch or VBUS regulator without feeding the ID pin / VBUS detection input correctly, the port may stay in a suspended/disconnected state even though 5V is present at the connector. Check the USB_VBUS_EN0/1 and related GPIO mappings.

3. SuperSpeed TX/RX lane polarity or swap. On custom boards the SSTX+/SSTX- and SSRX+/SSRX- pairs are often crossed or polarity-inverted. USB3 devices fall back to USB2 if the SS link cannot train, but first they must see a valid USB2 connection. Since you see no USB2 enumeration either, this is secondary to the D+/D- or VBUS-detect problem.

4. Hub vs direct routing. You mentioned “hub-routed port.” If there is an external USB3 hub between the SOM and the USB-A connector, make sure the hub is powered and its RESET/clock lines are asserted. An unpowered or held-in-reset hub will look like an open circuit.

5. Scope the connection event. With a scope or logic analyzer, watch D+ when you plug the camera in. You should see the device pull D+ high to signal a full/high-speed connection. If D+ stays low, the device does not think it is connected — usually because it does not see VBUS or because the D+/D- lines are not connected.

Can you confirm:

- Whether USB2-only devices (a simple flash drive) also fail silently on USB0?

- The exact connector/cable path from the SOM USB2-1/USB3-0 pads to the USB-A port?

- Whether the carrier has a hub, load switch, or ESD diode array in that path?

If a USB2 flash drive also fails silently, the issue is almost certainly D+/D- or VBUS detect, not SS lane mapping.

Hi,

Actually If I connect my USB2.0 Camera in that USB3.0 port(USB0), We can able to get the video successfully. But for USB3.0 camera, no dmesg case here.

I will check the VBUS sense case and let you know tomorrow.

Thanks.

Regards,
Kamalesh

Hi,

Update:-
We are not using any gpio to sense the 5v. We are using direct 5v from the custom board itself. I am using 5v regulator plugin in device tree which is already having always-on parameters.

Please help me to move forward.

Regards,
Kamalesh

Could you check if some simple usb device like mouse/keyboard is able to respond to the USB port or not?

Hi Wayne,

Yes, I tried mouse and keyboard. It is working. Also I tried usb2.0 camera with this port, that is also working.

Thanks.

Regards,
Kamalesh

The only method here is to use USB analyzer to check the bus trace. Otherwise we would only suggest you to review the hardware.

This kind of issue always follows such procedure.