How to trigger USB 3.0 TX Compliance Test / Eye Diagram on Orin NX with onboard USB Hub (Realtek RTS5420)?

Robotics & Edge Computing Jetson Systems Jetson Orin NX
,
1

Hi NVIDIA Team,

We are conducting USB 3.0/3.2 TX electrical compliance (eye diagram) testing on a custom carrier board powered by Jetson Orin NX (16GB).

  1. Hardware & System Setup:

• Module: Jetson Orin NX 16GB (P3767-0001)

• Carrier Board: Custom carrier board (designed based on P3768 architecture)

• L4T / JetPack Version: L4T R36.5.2 (JetPack 6.x), Kernel 5.15.199-tegra

• USB Topology:

Orin NX USB 3.2 Port 0 (HS_UPHY0_L0 @ 0x03610420, companion usb2-1) is routed directly on the PCB to the upstream port of an onboard Realtek RTS5420-GR (4-Port USB 3.2 Gen2 Hub).

The RTS5420-GR downstream ports are routed to external dual-stack USB 3.0 Type-A connectors.

The dedicated RTS5420 firmware provided by Realtek FAE has been flashed into the onboard SPI NOR flash.

Standard functional USB 3.0/2.0 operations are working properly (SuperSpeedPlus 10Gbps link verified via lsusb -t).

  1. What We Tried:

We followed the official Jetson Orin NX Series and Jetson Orin Nano Series Tuning and Compliance Guide (DA-11267-001 v1.3) section “Putting the Orin Module USB 3.2 Controller in Compliance Mode”:

Step 1: Unplugged all peripheral devices (mouse, keyboard, flash drives) from the external USB-A ports.

Step 2: Disabled autosuspend:

echo on > /sys/bus/usb/devices/usb1/power/control

echo on > /sys/bus/usb/devices/usb2/power/control

Step 3: Attempted to put Port 0 (HS_UPHY0_L0) into Compliance Mode via busybox devmem:

sudo busybox devmem 0x03610420 32 0x00010340

Step 4: Read back the PORTSC register:

PORTSC remains 0x00001663.

Bits[8:5] (PLS) remains 0x3 (U3/Suspended) and Bit 0 (CCS) remains 1 (Connected). It never transitions to 0xA (Compliance Mode).

  1. The Problem:

Because the Realtek RTS5420 hub is hard-soldered to the board, Orin xHCI Port 0 always sees CCS=1. Under standard xHCI/USB3 LTSSM specifications, writing PLS=0xA is ignored when the link is already active or in U3.

Furthermore, when we insert the USB 3.0 Compliance Test Fixture (with 50-ohm termination to the scope) into the external USB-A connector behind the RTS5420 hub, the downstream port does not output the CP0 compliance pattern.

  1. Questions:

  2. Scope of the Tuning Guide:

Is the register write procedure (devmem 0x03610420 w 0x10340) in DA-11267-001 exclusively intended for designs where the Orin root port is directly routed to an external USB connector without an intervening onboard hub?

  1. Testing Downstream Ports Behind an Onboard Hub:

What is the recommended procedure to put the downstream ports of an onboard USB 3.0 Hub (RTS5420) into USB 3.0 TX Compliance Test Mode on Jetson Linux?

• Does NVIDIA provide any userspace tool / xHCI debug command to send standard USB Hub Class Requests (SetPortFeature(PORT_TEST)) to put the hub downstream port into Compliance Test Mode?

• Or must the compliance mode of the external ports be triggered entirely by the Hub vendor’s proprietary utility/firmware?

  1. Testing Orin Root Port Directly:

If we want to probe the Orin TX differential signal directly at the AC coupling capacitors before the hub, what is the correct software procedure to force the Orin xHCI Port 0 into Compliance Mode when a soldered hub chip is physically present?

Thanks in advance for your guidance!

7

Hi,

The register procedure in the tuning guide controls the Orin root ports, it does not put the external hub’s downstream ports into compliance mode.

For testing the hub’s downstream ports, please consult the hub vendor or refer to the following discussion: The USB3.0 & USB2.0 compliance test method on nano devkit

For testing the Orin TX directly, the connected hub keeps the root port in an established link state (CCS=1 in your reported status). The register write alone does not transition the port from that state into compliance mode. Isolating the Orin root port signal would require a hardware modification to disconnect the hub from the link.

Thank you,

8

Hi,

Thank you for the clarification.

Our onboard hub is also the Realtek RTS5420-GR, which is the same USB 3.x hub device used on the P3768 reference carrier board.

I would like to further clarify the requirement for testing the Orin root-port TX directly.

Because the Orin SuperSpeed TX/RX differential pairs are directly routed to the RTS5420 on our PCB, it is difficult for us to physically disconnect and reconnect the high-speed differential pairs during the test.

Would it be sufficient to power off the RTS5420 (or hold the RTS5420 in reset) before putting the Orin USB 3.x root port into Compliance Mode, provided that the Orin PORTSC register then shows CCS=0?

For example, would the following sequence be valid?

1. Power off or hold the RTS5420 in reset
2. Verify that Orin xHCI PORTSC.CCS changes from 1 to 0
3. Put the Orin root port into Compliance Mode using the procedure in DA-11267-001
4. Measure the Orin TX signal at the AC-coupling capacitors / test point

Or does the RTS5420 need to be physically disconnected from the SuperSpeed TX/RX differential pairs, for example by removing 0-ohm resistors, even if the hub is completely powered off?

Also, since the P3768 reference carrier board itself uses an RTS5420 hub, could you please clarify how NVIDIA performs the Orin USB 3.x root-port TX compliance test on the P3768 board?

Specifically, does the P3768 compliance test require:

  • powering down/resetting the RTS5420,

  • removing/isolation of series/0-ohm components on the SuperSpeed differential pairs,

  • or some other hardware test configuration?

This would help us determine whether we need to modify our PCB for the Orin root-port TX compliance test.

Thank you.

9

Hi,

For your topology, TX compliance testing at the external USB connector measurements the hub’s downstream-port TX.

Could you clarify why you need to test the Orin root-port TX directly?

Are there any deviations from the USB layout guideline in the Jetson Orin Design Guide?

For the RTS5420’s behavior during reset or power-off, please consult Realtek.

We cannot share the internal test configuration.

Thank you,