USB-C w/PD Port Mapping

Hi,
I am working with a custom carrier board on the Jetson AGX Orin.

I am running Jetpack Version 5.1.2 with L4T 35.4.1.

The carrier board connectivity is very similar to the DevKit with a few tweaks. I am mostly trying to figure out if the adjustments that I made to the devicetree for compatibility are correct and if I need to reprogram the CYPD4226.

The port functions correctly for programming. The USB (2.0 & 3.x) signals are the same for the port, but the CYPD4226 signals are tied to the P1 port instead of the P2 port. Functionally, this is J39 for power and J40 for signals. As I mentioned prior, I can program using the port. I can also receive power in the system and have received ~30W of power through the port @ 20V. When the port is disconnected, I see 0V at VBUS, 0V at one CC pin, and 1.8V at the other CC pin.

In my device tree, the adjustments I’ve made are as follows:

In the I2C node, I swapped the contents of ccg_typec_con0 and ccg_typec_con1.
/* Edited because I found a type in that the ccg_typec_con1 was a subnode of ccg_typec_con0. I fixed that, but the system is still not working.
i2c@c240000 {

		ucsi_ccg: ucsi_ccg@8 {
			status = "okay";
			compatible = "nvidia,ccgx-ucsi";
			ccgx,firmware-build = "gn";
			reg = <0x08>;
			interrupt-parent = <&tegra_main_gpio>;
			interrupts = <TEGRA234_MAIN_GPIO(Y, 4) IRQ_TYPE_LEVEL_LOW>;
			interrupt-names = "wakeup";
			wakeup-source;
			ccg_typec_con0: connector@0 {
				compatible = "usb-c-connector";
				label = "USB-C";
				data-role = "dual";
				port {
					ucsi_ccg_p0: endpoint {
						remote-endpoint = <&usb_role_switch0>;
					};
				};
			};
			ccg_typec_con1: connector@1 {
				compatible = "usb-c-connector";
				label = "USB-C";
				data-role = "host";
			};
		};


};

Under the xusb_padctl: xusb_padctl@3520000 node, I set the remote-endpoint for usb2-0 to _p0 instead of _p1:

ports {
 			usb2-0 {
 				mode = "otg";
 				usb-role-switch;
 				status = "okay";
 				port {
 					usb_role_switch0: endpoint {
 						remote-endpoint = <&ucsi_ccg_p0>;
 					};
 				};
 			};

I don’t believe any other changes should be required unless there are updates needed in the CYPD4226 programming as well.

For some additional details, if I fully disconnect the system --DC Power & USB – then plug in USB, turn on DC power, then boot the system to Linux, the I2C works fine even though USB does not. I can unplug and plug in the USB connected to the laptop and I2C continues to function. If I unload the module then reload it, the I2C port no longer responds until a reboot.

The messages I get, when I2C has dropped out, are as follows:

[ 1619.298413] tegra-i2c c240000.i2c: I2C transfer timed out
[ 1619.304615] ucsi_ccg 1-0008: i2c_transfer failed -110
[ 1627.798463] tegra-i2c c240000.i2c: I2C transfer timed out
[ 1627.805720] ucsi_ccg 1-0008: i2c_transfer failed -110
[ 1627.811010] ucsi_ccg 1-0008: ucsi_ccg_init failed - -110
[ 1627.817651] ucsi_ccg: probe of 1-0008 failed with error -110

Full dmesg attached.
dmesg_usb.txt (76.5 KB)

Thanks for any help,
Joe

Hi,

So did the CYPD4226 get programmed already or not?

Yes, my team confirmed the CYPD4226 was programmed with the nvidia provided firmware (Cypress Firmware Binary for USB Type-C PD controller (CYPD4226) ). Thanks!

lsusb outputs. This was during a boot where the USB was connected, then power applied to the system.
lsusb -tv
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 10000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
ID 05e3:0610 Genesys Logic, Inc. 4-port hub
|__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
ID 413c:301a Dell Computer Corp.
|__ Port 3: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
ID 413c:2113 Dell Computer Corp.
|__ Port 3: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
ID 413c:2113 Dell Computer Corp.
|__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=rtl8192cu, 480M
ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
|__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/7p, 480M
ID 0424:2507 Microchip Technology, Inc. (formerly SMSC) hub

Hi,

Just to clarify, which firmware got flashed there?

Could you share a schematic or diagram and explain your exact problem now? It looks like you are talking about one port does not work fine and vbus is 0V?

The firmware that was flashed on the CYPD4226 was the nVidia provided firmware. I believe it matches the Devkit firmware.

I’ll be able to put together a diagram when I’m back at my computer, but the port is functionally the DevKit’s south port with the USB signals (both USB2 and USB3 signals) from the North/Flashing port.

I am able to receive power on the port (allowing the system to run with no other power source) and flash in recovery mode, but nothing else works on the port.

Thanks Wayne. Your assistance on this bring up effort has been invaluable.

The firmware that was flashed on the CYPD4226 was the nVidia provided firmware. I believe it matches the Devkit firmware.

I mean from which website/link?

I am able to receive power on the port (allowing the system to run with no other power source) and flash in recovery mode, but nothing else works on the port.

The behavior from recovery mode may not be helpful as recovery mode is a pure hardware triggered event. Our software does not involve to it.

Good question. That flash was done by my hardware guys so I will need to follow up with them to get that info. Can you provide a link for the correct firmware?

When I checked, I only saw one link and the title of it was what I put in my prior post. the time stamp is 4/12/2019. I just checked again and the only firmware I see on there is the AGX Xavier Eval Kit.

Is this my problem?

Hi,

I am afraid that the firmware seems to be wrong.

Orin and Xavier fw are different. Orin firmware is over this page.

Hi Wayne,

AGX Xavier was the one we had loaded. We’re going to try switching the firmware and see how it goes. Hopefully my device tree changes were correct for the board as I described it. I’ll update once we have more info.

Thanks,
Joe

Hi Wayne, the devicetree changes I called out in my original post and the updated firmware fixed the issue. Thanks for your help!

1 Like