Issues with USB Port Configuration and OTG Power Management on Jetson Orin NX 3768-0000-3767-0000 Carrier + Core Board

Hello,

I am encountering some issues with the USB port configuration and OTG power management on the NVIDIA Jetson Orin NX 3768-0000-3767-0000 carrier board and core board. Below is a detailed description of the problem:

  1. In the official configuration of the Jetson Orin NX 3768-0000-3767-0000 carrier + core board, the following USB ports are enabled respectively:
  • usb2-0 (Type-C)
  • usb2-1 (Type-A)
  • usb2-2 (M.2 E-key)
  • usb3-0 (Type-A bound to usb2-1)
  • usb3-1 (Type-C bound to usb2-0)
    The hardware schematics and DTS files have been verified to be consistent. Please see attachments 1 and 2.

disable-all-expect-usb2-0.txt (42.7 KB)

  1. For a custom-designed carrier board, only the usb2-0 and usb3-1 Type-C ports are used according to our needs. The fusb301tmx chip logic is the same. The rts5420 hub chip corresponding to usb2-1 and usb3-0 is not used, so the rts5420 chip and Type-A ports are not soldered.
    When disabling usb2-1 and usb3-0 in the DTS (disabling the corresponding lanes and ports in the device tree and removing them from usb@3610000), and confirming the changes take effect, an OTG device insertion triggers a power management error.
    The fusb301 pin signals and problem logs during device insertion are attached in attachments 3 and 4.
    (Note: If the inserted OTG device supports external power supply, it works normally, but only after the first power-on. After unplugging and re-plugging, the device becomes invisible.)Based on the issue described in point 2, restoring the DTS or removing the rts5420 chip from the official 3768-0000-3767-0000 carrier board results in the same problem, with no obvious difference. See attachments 3 and 4.

jetson-orin-nx-custom-carrier-board-usb-error.txt (64.2 KB)

  1. If all USB ports are disabled except usb2-0 on the usb3550000 branch, the error disappears, and the fusb301 chip can recognize plug/unplug events without errors. However, the device cannot function as a host. See attachment 5.
    disable-all-expect-usb2-0.txt (42.7 KB)

  2. By enabling full logs and tracing the issue to HCI management, the problem is identified as the HCI manager not responding after tegra_xhci_set_port_power sets HS port power following OTG device insertion. Logs are in attachment 6.

  3. Additionally, on a normal 3768-0000-3767-0000 board (without any hardware modification), if only usb2-0 and usb3-1 are kept in the driver (disabling all other lanes and ports), the same issue can be reproduced (attachment 7).
    change.txt (15.3 KB)

This is confusing.
Also, in the original configuration, the phynames seem to be incorrectly assigned. Changing phynames to usb3-0 causes the Linux port to malfunction.

Our request:
We want to remove the rts5420 chip and have the Type-C usb2-0 and usb3-1 ports work properly both as host and device. Could you please advise on the correct software-level modifications needed to achieve this?

Thank you very much for your help.

Hi,

Also, in the original configuration, the phynames seem to be incorrectly assigned. Changing phynames to usb3-0 causes the Linux port to malfunction.

Please keep the phyname as usb3-0. It is upstream kernel rule that is has to start from usb3-0.
It is not a bug. It is just we follow the upstream kernel rule. Please do not modify it.

I don’t think the “change.txt” things you put there are correct too. Do not modify things to usb3-1 in phyname as I mentioned here.

Also, please do not put other noises from Orin AGX DT. They are totally not related.

xhci-tegra.c/xusb-tegra186.c/xusb.c do not need patch either. Do not change anything in these drivers.
The only thing you need to do is modify the device tree. Share us what is your final dts looks like and how your schematic looks like.

thanks for the quick reply. Just remove the rts5420 on the schematic and no other changes. The dts is like below

   padctl@3520000 {
		status = "okay";

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

					usb2-1 {
						nvidia,function = "xusb";
						status = "disabled";
					};

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

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

					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_1v1_hub>;
				status = "disabled";
			};

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

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

			/* 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-0";
	};

	usb@3610000 {
		status = "okay";

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

please convert your final dtb back to dts and share that one.

Thanks a lot wayne.

It is your first answer that solved my problem. I found that the error is not caused by the rts5420, it is because the usb2-2. I did not connect the wifi module to the M.2E.

Could you please explain why it caused the error when I connect an OTG on typeC port?

Hi,

I have no idea about that. Theoretically it would not. More like hardware problem to me.

Hi wayne,

BTW, if you have a jetson orin nx by your side, you could try to remove the wifi/bt module on the M.2E KEY. Use ‘sudo dmesg -n 7’. And connect an OTG device on typeC。 You could find the error below. The only relationship between USB2-0 and USB2-2 is the vbus-supply. Is there any idea?

[   48.136325] fusb301 1-0025: fusb301_work_handler: int_sts[0x01]
[   48.136903] fusb301 1-0025: sts[0x11], type[0x10]
[   48.137739] fusb301 1-0025: fusb301_set_dfp_power: host current(1)
[   48.137750] fusb301 1-0025: fusb_update_state: 7
[   48.137758] (null) usb2-0: tegra_xusb_role_sw_set(): role host
[   48.137830] (null) usb2-0: tegra_xusb_usb_phy_work(): calling notifier for role host
[   48.137838] tegra-xusb 3610000.usb: tegra_xhci_id_notify(): action is 2
[   48.137846] tegra-xudc 3550000.usb: tegra_xudc_vbus_notify(): event is 2
[   48.137851] tegra-xudc 3550000.usb: Same role(0) received. Ignore
[   48.137856] tegra-xusb 3610000.usb: host mode on
[   48.137867] (null) usb2-0: tegra186_utmi_phy_set_mode: mode 11
[   48.137871] tegra-xusb-padctl 3520000.padctl: set id override
[   48.137876] tegra-xusb-padctl 3520000.padctl: 00000360 > 00011000
[   48.137881] tegra-xusb-padctl 3520000.padctl: 00000360 < 00011000
[   48.137903] tegra-xusb 3610000.usb: tegra_xhci_set_port_power():set SS port power
[   48.137908] xhci_hub_control :SetPortFeature
[   48.137912] xhci_hub_control :SetPortFeature 8
[   48.137914] xhci_hub_control :1111111 1 4
[   48.137920] tegra-xusb 3610000.usb: xHCI host controller not responding, assume dead
[   48.137924] tegra-xusb 3610000.usb: HC died; cleaning up
[   48.137924] CPU:0, Error: cbb-fabric@0x13a00000, irq=179
[   48.137939] tegra-xusb 3610000.usb: HCD shut down
[   48.137939] **************************************
[   48.137944] CPU:0, Error:cbb-fabric, Errmon:2
[   48.137953]    Error Code            : PWRDOWN_ERR
[   48.137964]
[   48.137967]    Error Code            : PWRDOWN_ERR
[   48.137971]    MASTER_ID             : CCPLEX
[   48.137974]    Address               : 0x3610430
[   48.137978]    Cache                 : 0x1 -- Bufferable
[   48.137985]    Protection            : 0x2 -- Unprivileged, Non-Secure, Data Access
[   48.137991]    Access_Type           : Read
[   48.137994]    Access_ID             : 0x16
[   48.137998]    Fabric                : cbb-fabric
[   48.138002]    Slave_Id              : 0x22
[   48.138005]    Burst_length          : 0x0
[   48.138009]    Burst_type            : 0x1
[   48.138012]    Beat_size             : 0x2
[   48.138014] tegra-xusb 3610000.usb: HCD shut down
[   48.138015]    VQC                   : 0x0
[   48.138019]    GRPSEC                : 0x7e
[   48.138022]    FALCONSEC             : 0x0
[   48.138026]    Slave                 : AXI2APB_16
[   48.138031]  **************************************
[   48.138045] tegra-xusb 3610000.usb: HCD shut down
[   48.138071] ------------[ cut here ]------------
[   48.138073] tegra-xusb 3610000.usb: HCD shut down
[   48.138075] WARNING: CPU: 0 PID: 0 at drivers/soc/tegra/cbb/tegra234-cbb.c:608 tegra234_cbb_isr+0x144/0x190
[   48.138096] Modules linked in: nvidia_modeset(O)
[   48.138100] tegra-xusb 3610000.usb: HCD shut down
[   48.138104]  lzo_rle(E) lzo_compress(E) zram(E) zsmalloc(E) ramoops(E) reed_solomon(E) bridge(E) stp(E) llc(E) usb_f_ncm(E) usb_f_mass_storage(E) rfkill(E) usb_f_acm(E) u_serial(E)
[   48.138128] tegra-xusb 3610000.usb: HCD shut down
[   48.138129]  usb_f_rndis(E) u_ether(E) libcomposite(E) snd_soc_tegra210_mvc(OE) snd_soc_tegra210_admaif(OE) s

please share us how you modified the device tree to reproduce this error.

Your previous change has lots of unnecessary items in it. If you want to discuss this, I think you should use clean setup with only device tree change.

Let me explain. With your first replay I have already reset all the changes that I made.

Now, no need to make any changes in the dts nor in the kernel drivers.

Just remove the wifi/bt hardware on the offical carrier board and nx 16g core board 3768-0000-3767-0000 of nvidia, that could recurrence the same error above.

Hi,

We tried the test you mentioned here on rel-36.4.3 3768-0000-3767-0000 board. But I don’t see any error from type C port after removing the M.2 wifi card on the board.

After that, did you try to connect an otg device on TYPEC(usb2-0/usb3-1) ?

Yes, we did.

Interesting. Let me reset all again, and make another try later. Thanks a lot.

Please try rel-36.4.3 and also share clear dmesg and also what kind of device you are testing there is you could really reproduce this every time.

1 Like

I forget to say that I am now working on jetpack 6.0, l4t 36.3.0. Anything different with this version?

We didn’t hear about such issue before from other users before.

This is not a known issue.

May I ask which type of OTG device you are using.
Which reasons for USB2-0 OTG recognition failure when USB2-2 is not connected to any external device based on current LOG

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