USB under JetPack 6.2 on custom carrier board

We have designed a carrier board that we have successfully used with the Jetson Xavier NX; it is also currently working with the Jetson Orin NX using JetPack 5.1.4.

When we attempt to install JetPack 6.2, the module flashes and boots but USB is unavailable. Using l4t_create_default_user.sh to create a pre-configured image, we have been able to ssh into the system and have observed the following in the kernel log:

[ 2.916754] usb 1-2: new full-speed USB device number 2 using tegra-xusb
[ 3.045079] usb 1-2: device descriptor read/64, error -71
[ 3.281084] usb 1-2: device descriptor read/64, error -71
[ 3.516757] usb 1-2: new full-speed USB device number 3 using tegra-xusb
[ 3.644784] usb 1-2: device descriptor read/64, error -71
[ 3.881086] usb 1-2: device descriptor read/64, error -71
[ 3.988862] usb usb1-port2: attempt power cycle
[ 4.432757] usb 1-2: new full-speed USB device number 4 using tegra-xusb
[ 4.433149] usb 1-2: Device not responding to setup address.
[ 4.641147] usb 1-2: Device not responding to setup address.
[ 4.848754] usb 1-2: device not accepting address 4, error -71
[ 4.976588] usb 1-2: new full-speed USB device number 5 using tegra-xusb
[ 4.976910] usb 1-2: Device not responding to setup address.
[ 5.184784] usb 1-2: Device not responding to setup address.
[ 5.392585] usb 1-2: device not accepting address 5, error -71
[ 5.392683] usb usb1-port2: unable to enumerate USB device

The carrier board uses a TUSB2046BI hub for USB2 connectivity. The board does not support USB3.

We are currently using the default device tree. The same installation works when the NVMe and SoM are hosted on the carrier board from the Xavier NX development kit. In the past, the default device tree has not caused any problems with USB.

Are there any changes that need to be made to the device tree (or the kernel) if the hub on the carrier board does not support USB3? As I say, USB is fine with the same Orin NX SoM under JetPack 5.1.4 so the hardware is fine.

Device tree change is always required. Your concept that you could use default setting for custom board is wrong. That rel-35 success was just a luck.

Please read the L4T developer guide for the USB porting guide.

Thank you. Unfortunately, the documentation is not clear on how to port L4T 36.4.3 to a board without USB2. I have removed the references to the FUSB301 and I have also removed the USB3 entries from the ports and pads under padctl@3520000. I have removed the USB3 references from the phys sections of usb@3550000 and usb@3610000. However, I still see an error -71 on bootup and am unable to see the USB2 hub on the carrier board.

The USB2 hub is on USB1 (pins 115 and 117 of the SoM) and there is also a device port on USB0 (pins 109 and 111 of the SoM) which is brought out to a micro USB connector. The board is visible over the microUSB connector to the host PC when in recovery mode but not once the OS has booted.

please share schematic/dmesg and also the device tree converted back from dtb.

I have attached the device tree and the dmesg log. The full schematics are company confidential but I have attached screenshots showing the relevant USB connections.

dmesg.log (60.0 KB)
jetstream-orin-6.2.dts.txt (313.1 KB)


Hi,

We notice there is no such prod-settings field in your device tree.

Could you check why your DT does not include that? It should be in hardware/nvidia/t23x/nv-public/nv-soc/tegra234-soc-prod-overlay.dtsi

The file that I sent has the following at line 5911:

  xusb_padctl@3520000 {

  	prod-settings {
  		#prod-cells = <0x04>;

  		prod {
  			prod = <0x00 0x284 0x38 0x38 0x00 0x288 0x3fff000 0x51e000>;
  		};
  	};
  };

I can confirm that the lines are present in hardware/nvidia/t23x/nv-public/nv-soc/tegra234-soc-prod-overlay.dtsi:

            xusb_padctl@3520000 {
                    prod-settings {
                            #prod-cells = <4>;
                            prod {
                                    prod = <
                                            0 0x00000284 0x00000038 0x00000038              //XUSB_PADCTL_USB2_BIAS_PAD_CTL_0_0
                                            0 0x00000288 0x03fff000 0x0051e000>;            //XUSB_PADCTL_USB2_BIAS_PAD_CTL_1_0
                            };
                    };
            };

I have not modified said file; it has its original datestamp of Jan 8 01:10.

Hi,

It looks like the original DT has mistake. Please apply this.

diff --git a/nv-soc/tegra234-soc-prod-overlay.dtsi b/nv-soc/tegra234-soc-prod-overlay.dtsi
index 7725c61..8777024 100644
--- a/nv-soc/tegra234-soc-prod-overlay.dtsi
+++ b/nv-soc/tegra234-soc-prod-overlay.dtsi
@@ -540,7 +540,7 @@
 			};
 		};
 
-		xusb_padctl@3520000 {
+		padctl@3520000 {
 			prod-settings {
 				#prod-cells = <4>;
 				prod {

Unfortunately, making that change has had no apparent effect. I have attached the latest dump of the device tree and the kernle log from dmesg.

dmesg-250522.log (59.5 KB)
jetstream-orin-6.2-250522.dts.txt (313.1 KB)

As a further update, we have a plugin card that uses the USB_HS2 lines (SoM pins 121 and 123) to host a microcontroller. When said card is plugged in, the microcontroller is visible over USB. This would imply that one port of the USB2 controller is working at least.

Additionally, we have tried removing the pull-up resistor (R166) for the USB_HS1_P line to see whether it had any effect; this resulted in the TI USB hub not being detected at all, as opposed to giving a -71 error in the kernel log.

We appear to have found the problem: the USB reset is derived from the PCIe reset line, which is held low during the USB enumeration, hence the detection fails. We are currently looking into whether the board can be modified to use an alternative reset. In the meantime, is there any way to configure the firmware not to hold the PCIe bus in reset during bootup?

If the hardware is wrong that you connect USB things to PCIe control signal, then no, there is no such method in software to configure.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.