Lack of USB3.0

[igal.kroyter]

Hi,

I have two Jetsons which are configured to Configuration #3 (flashed with ODM-DATA 0x6090000):

ls -l /proc/device-tree/chosen/plugin-manager/odm-data
total 0
-r--r--r-- 1 root root 4 Sep  2 06:57 android-build
-r--r--r-- 1 root root 4 Sep  2 06:57 disable-pmic-wdt
-r--r--r-- 1 root root 4 Sep  2 06:57 disable-sdmmc-hwcq
-r--r--r-- 1 root root 4 Sep  2 06:57 disable-tegra-wdt
-r--r--r-- 1 root root 4 Sep  2 06:57 enable-debug-console
-r--r--r-- 1 root root 4 Sep  2 06:57 enable-denver-wdt
-r--r--r-- 1 root root 4 Sep  2 06:57 enable-pcie-on-uphy-lane0
-r--r--r-- 1 root root 4 Sep  2 06:57 enable-pcie-on-uphy-lane4
-r--r--r-- 1 root root 4 Sep  2 06:57 enable-sata-on-uphy-lane5
-r--r--r-- 1 root root 4 Sep  2 06:57 enable-xusb-on-uphy-lane1
-r--r--r-- 1 root root 4 Sep  2 06:57 enable-xusb-on-uphy-lane2
-r--r--r-- 1 root root 9 Sep  2 06:57 name
-r--r--r-- 1 root root 4 Sep  2 06:57 no-battery
-r--r--r-- 1 root root 4 Sep  2 06:57 normal-flashed

One of the Jetsons provide access to USB3.0 while the other does not.
The difference in the device tree is as following:
The working module:

chosen {
		reset {
			pmc-reset-reason {
				[b]reset-source = "BCCPLEXWDT";
				reset-level = [31 00];[/b]
			};

			pmic-reset-reason {
				<b>register-value = "0x00";</b>
				reason = "NIL_OR_MORE_THAN_1_BIT";
			};
		};

The non working module:

chosen {
		bootargs = <b>...tegra_fbmem2=0x800000@0x969ee000 lut_mem2=0x2008@0x969eb000 ...</b>
		reset {

			pmc-reset-reason {
				<b>reset-source = "SYS_RESET_N";</b>
				<b>reset-level = [30 00];</b>
			};

			pmic-reset-reason {
				<b>register-value = "0x4f";</b>
				reason = "NIL_OR_MORE_THAN_1_BIT";
			};
		};

I have emphasized the differences. Could these differences cause the lack of USB3.0 communication?
No communication = no identification of USB3.0 devices or even print outs on the terminal
Regards.

[DaneLLL]

Hi,
For two Jetsons, do you mean your own custom boards? The default board is in config #2 and cannot run config #3.

[igal.kroyter]

Hi,
By two Jetsons I mean two jetson modules connected to our custom board - not at the same time. I configured both of the modules to cfg #3, as you may see above they share the same ODM DATA. But I think that the working one was flashed with 28.1 tree and the non working with 28.2.1.
Anyway these are the differences, between the modules that I’ve found.
Any ideas?

[DaneLLL]

Hi,
You may check VBUS. Please check if it is turned on after booting to kernel, and if the voltage is as expected.

We have seen issues when VBUS is on before booting to kernel.
[url]https://devtalk.nvidia.com/default/topic/1036547/jetson-tx1/usb2-b43-b42-not-working-on-tx1-with-r28-2/post/5265708/#5265708[/url]
[url]https://devtalk.nvidia.com/default/topic/1043644/jetson-tx2/usb1-and-installing-kernel-modules-for-lte-modem/post/5294983/#5294983[/url]

[igal.kroyter]

DaneLLL hi,
I’m not sure that I know how to disable and renewable the VBUS. I read the links one of the customers just said that he did it, while another recycled USB2 regulator and the 3rd has shut down the VBUS through kernel code. Could please elaborate?
Thanks.

[DaneLLL]

Hi igal,
You need to check HW layout of USB port. VBUS may be linked to regulator of PMIC or a TX2 GPIO pin. It may be turned on earlier at bootloader stage.

[igal.kroyter]

DaneLLL, hi,

we have the USB1_EN_OC# A18 (per pinmux it is GPIO3_PL.05) pin from the TX2i connected to a USB power-distributor switch which provides the 5[V] to the USB port.
So I understand from you that I have to apply an OFF->ON cycle on this pin after the kernel has completed loading. Am I correct? and how do I do it?
Regards.

[DaneLLL]

Hi igal,
Do you have one TX2 module and one TX2i module?
r28.1 does not support TX2i. You have mention it works on r28.1, so the module should be TX2.

TX2 and TX2i runs different dtb, is it possible you don’t make modification to right dtsi?
[url]Jetson/TX2 USB - eLinux.org

[igal.kroyter]

DaneLLL, hi,
I have patched correctly and used the correct files for TX2i. As I wrote before I have printed out the actual device tree from each device while it is running. Could you please look back in message #1 and let me know whether the differences can impact this issue?

[DaneLLL]

Hi igal,
From device tree comparison in message #1, it looks not related to USB3 functionality.

So it works on r28.1+TX2 and fails on r28.2.1+TX2i. Is this correct? Since r28.1 does not support TX2, it seems your one module is TX2 and the other is TX2i.
In failure case, do you see any error in kernel log?

[igal.kroyter]

DaneLLL, hi,

I think that I confused you. At first when we got the TX2i the r28.2.1 was not released yet so we used r28.1.
I was just wondering whether it is possible that they have different revisions.

Both CPUs are TX2i.

The only error that I found in the terminal log was

[    4.499401] xhci-tegra 3530000.xhci: Direct firmware load for tegra18x_xusb_firmware failed with error -2
[    4.499403] xhci-tegra 3530000.xhci: Falling back to user helper

but both CPUs share this error.

Any suggestions?

[DaneLLL]

Hi igal,
In config #3, PER_RFU(G39/G40/D39/D40) and USB_SS1(G42/G43/D42/D43) are enabled. Are both not working? Is A18 with PEX_RFU or USB_SS1?

[igal.kroyter]

DaneLLL, hi,

We are using the USB_SS1(G42/G43/D42/D43) (PER_RFU(G39/G40/D39/D40) is not connected).

The A18 enabler is utilized as an Enable GPIO for both USB3.0(USB_SS1) and USB2.0(USB2 (B42,B43).

This USB2.0 is utilized for Keyboard and Mouse which are working with both Modules.

BTW, the enabler of the above USB2.0 (USB2_EN_OC - A19 )is not used.

Both PCI lanes (PEX1 & PEX2) work for both Modules.
SATA works for both Modules.
From the above, I guess Configuration #3 is OK.

Any Suggestions?

[DaneLLL]

Hi igal,
Do you see usb3-2 present under xhci

$ xxd /proc/device-tree/xhci@3530000/phy-names

And under pinctrl

$ xxd /proc/device-tree/pinctrl@3520000/pinmux/_USER_DEFINED_NAME_/nvidia\,lanes

When no device is connected, is VBUS shutdown at 0v?
Once a device is connected, is VBUS turned on at 5V and enumeration triggered?

[igal.kroyter]

DaneLLL, hi,

xxd /proc/device-tree/xhci@3530000/phy-names
00000000: 7574 6d69 2d30 0075 746d 692d 3100 7574  utmi-0.utmi-1.ut
00000010: 6d69 2d32 0075 7362 332d 3100 7573 6233  mi-2.usb3-1.<b>usb3</b>
00000020: 2d32 00                                  <b>-2</b>.

xxd /proc/device-tree/pinctrl@3520000/pinmux/usb3-std-A-port3/nvidia\,lanes
00000000: 7573 6233 2d32 00                        <b>usb3-2</b>.

The VBUS is always ON to both USB ports (USB2.0 and USB3.0).
Though there is no triggering on the module that does not work, while on the other module we do have a triggering process.

[DaneLLL]

Hi igal,
The device tree looks OK. As of now it still looks like VBUS is on too early. Suggest you turn off and turn on VBUS after booting to kernel and see if enumeration gets triggered. Or try to turn VBUS on after xusb fw is loaded.

[igal.kroyter]

DaneLLL, hi,

The following questions are as a result of lack of knowledge so if you could explain I’ll appreciate it:

1. "...VBUS is on too early" - for which? the Jetson module or the device? I connect the device long after the module is on.
2. I think that the only way that I can trigger the VBUS is via the A18 GPIO - how do I trigger it via terminal? via code? - any pointers to implemented code if available.
3. Does A18 has any affect on the module besides the fact that it is used as an GPO?

Regards.

[DaneLLL]

Hi igal,

“…VBUS is on too early” - for which? the Jetson module or the device? I connect the device long after the module is on.
I think that the only way that I can trigger the VBUS is via the A18 GPIO - how do I trigger it via terminal? via code? - any pointers to implemented code if available.

It is earlier than xhci is initialized.

[    9.016118] xhci-tegra 3530000.xhci: Firmware timestamp: 2017-12-07 10:50:08 UTC, Version: 55.09 release
[    9.029636] xhci-tegra 3530000.xhci: xHCI Host Controller
[    9.029650] xhci-tegra 3530000.xhci: new USB bus registered, assigned bus number 1
[    9.030473] xhci-tegra 3530000.xhci: hcc params 0x0184fd25 hci version 0x100 quirks 0x00010810
[    9.030497] xhci-tegra 3530000.xhci: irq 59, io mem 0x03530000

Please check when you enable the GPIO.

Does A18 has any affect on the module besides the fact that it is used as an GPO?

It is over current detection pin. It is enabled if below is put in device tree:

nvidia,oc-pin = <1>;

A17 is

nvidia,oc-pin = <0>;

[igal.kroyter]

DaneLLL, hi,

I don’t enable the OC pin manually it is set in the device tree. I saw that OC is parsed in kernel kernel/t18x/drivers/pinctrl/pinctrl-tegra186-padctl.c.

I could add some printing when the device tree is parsed to see it relative to the xhci-tegra initialization but I do not know where the kernel activate the OC. Do you want me to apply it?

My device tree per the OC is following:

pinmux {
			phandle = <0x96>;
			linux,phandle = <0x96>;

			usb2-std-A-port2 {
				nvidia,function = "xusb";
				nvidia,lanes = "otg-1";
				nvidia,port-cap = <0x1>;
				status = "okay";
				nvidia,oc-pin = <0x1>;
			};

			usb3-std-A-port2 {
				nvidia,lanes = "usb3-1";
				nvidia,port-cap = <0x1>;
				status = "okay";
				nvidia,oc-pin = <0x1>;
			};

			usb3-std-A-port3 {
				nvidia,lanes = "usb3-2";
				nvidia,port-cap = <0x1>;
				status = "okay";
				<b>nvidia,oc-pin = <0x1>;</b>
			};

			e3325-usb3-std-A-HS {
				nvidia,function = "xusb";
				nvidia,lanes = "otg-2";
				nvidia,port-cap = <0x1>;
				status = "okay";
			};

			e3325-usb3-std-A-SS {
				nvidia,lanes = "usb3-0";
				nvidia,port-cap = <0x1>;
				status = "disabled";
			};

			usb2-micro-AB {
				nvidia,function = "xusb";
				nvidia,lanes = "otg-0";
				nvidia,port-cap = <0x3>;
				status = "okay";
				nvidia,oc-pin = <0x0>;
			};
		};

should I set the nvidia,oc-pin under usb3-std-A-port3 to <0>?
Regards.

[DaneLLL]

Hi igal,
You should remove all nvidia,oc-pin if you don’t use the pins.

And we suggest you try HW reset since it helps another user:
[url]https://devtalk.nvidia.com/default/topic/1043644/jetson-tx2/usb1-and-installing-kernel-modules-for-lte-modem/post/5294983/#5294983[/url]
If you can get help from HW engineers, please try HW reset.