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.
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.
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.
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?