Hi Team,
we working on custom board with AGX Xavier SoM, need some help on USB bring up on custom board.
To USB 3.1 Type -A port on custom board these lines are connected,
1. USB1_DN and USB1_DP for USB 2.0 support
2. UPHY_TX6 and UPHY_RX6 for USB 3.0 support
Please let us know the changes required in device tree to configure this.
Thanks,
Arun
Please directly refer to the usb porting guide in adaptation guide.
Hi @WayneWWW ,
We are having a USB 3.1 Type A connector in our board, with UPHY6 for USB 3.1 and USB1 for USB 2.0. Is this requires any additional change in dts and cfg? Could you please suggest us those changes?
Thanks,
Arun
I already suggested. Please check the document.
Hi @WayneWWW ,
I went through the documentation. I am not clear about where should we mention that UPHY6 is used in dts?
Thanks,
Arun
The document already wrote below info.
The USB3.1 signal pairs are wired to UPHY lane 6 (USB3.1 port 0 according to UPHY
lane mapping).
Hi @WayneWWW ,
Following is usage of USB in our board
| USB | Custom board usage |
|---|---|
| USB 2.0 Port0, UPHY1 (USB 3.1 Port2) | 3.1 Type-C (OTG) |
| USB 2.0 Port1 UPHY6 (USB 3.1 Port0) | 3.1 Type-A (Host) |
| USB 2.0 Port2 | 2.0 Hub (Host) |
| USB 2.0 Port3 | 2.0 Hub (Host) |
I have did the following changes in the device tree by following the platform bringup and adaptation guide:
xusb_padctl: xusb_padctl@3520000 {
status = "okay";
pads {
usb2 {
lanes {
usb2-0 {
nvidia,function = "xusb";
status = "okay";
};
usb2-1 {
nvidia,function = "xusb";
status = "okay";
};
usb2-2 {
nvidia,function = "xusb";
status = "okay";
};
usb2-3 {
nvidia,function = "xusb";
status = "okay";
};
};
};
usb3 {
lanes {
usb3-0 {
nvidia,function = "xusb";
status = "okay";
};
usb3-2 {
nvidia,function = "xusb";
status = "okay";
};
};
};
};
ports {
usb2-0 {
mode = "otg";
status = "okay";
};
usb2-1 {
mode = "host";
status = "okay";
};
usb2-2 {
mode = "host";
status = "okay";
};
usb2-3 {
mode = "host";
status = "okay";
};
usb3-0 {
nvidia,usb2-companion = <1>;
status = "okay";
};
usb3-2 {
nvidia,usb2-companion = <0>;
status = "okay";
};
};
};
tegra_xudc: xudc@3550000 {
phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-0}>,
<&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-2}>;
phy-names = "usb2", "usb3";
nvidia,xusb-padctl = <&xusb_padctl>;
nvidia,boost_cpu_freq = <1200>;
status = "okay";
};
tegra_xhci: xhci@3610000 {
phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-0}>,
<&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-1}>,
<&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-3}>,
<&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-2}>,
<&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-2}>;
<&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-0}>;
phy-names = "usb2-0", "usb2-1", "usb2-3", "usb2-2",
"usb3-2","usb3-0";
nvidia,xusb-padctl = <&xusb_padctl>;
status = "okay";
};
and have deleted the nodes head0,head1 and head2 from the common.dtsi file.
These are the only changes made. But none of the USB is working. But in the c-boot, I got the logs checking for USB boot when I connect USB pendrive in 2.0 Hubs and 3.1 Type-A Host.
Can you suggest some ways to debug the issue?
Thanks,
Arun
Please share a dmesg when you want to bring up something on custom board.
Also, you have the type C here, but do you have the PD controller?
If not, then for the otg, you need to write the extcon table for vbus and id pin. This is also mentioned in the document.
Hi @WayneWWW,
Yes, we have PD controller but not same as the AGX Xavier devkit. But still other USBs are also not working,
I have attached the dmesg logs below.
dmesg_custom.txt (68.1 KB)
Thanks,
Arun
Hi,
I am not sure if we can support the case of other PD controller. Could you add the extcon back first and share the log?
Currently, xudc gets error with below error.
[ 1.886891] tegra-xudc-new 3550000.xudc: extcon_get_extcon_dev_by_cable failed -19
The extcon is needed for the otg one to control the vbus and id pin behavior.
Another problem is we don’t guarantee the behavior of other PD controller from the Cypress one we are using on devkit. I could only suggest you could add those extcon back for the type C port you are using.
We don’t have other users here, at least during my experience, using their own PD controller.
Hi @WayneWWW,
Is there anything wrong/needed additionally for 3.1 Type connector and the two 2.0 USB Hubs to work?
Thanks,
Arun
Hi,
If you are talking about just leave the type C not working and verify other ports first, then please just disable that lane (both 2.0 and 3.0 ) and that port in device tree first. Also, remove it from xudc and xhci.
Hi @WayneWWW,
After disabling the Type-C related USB nodes, the other type-A connectors in the board started to work. Thank you.
I have tried configuring the Type-C mode as “host” instead of “otg” and haven’t added extcon in dts. In this case, the Type-A ports are working. But still Type-C is not getting detected.
Thanks,
Arun
The type C hardware is already different from the type A. Thus, just modifying mode to host is not sufficient.
However, we are also not sure if your PD controller would work or not. We have similar case on devkit to change one type C to device mode only. In this case, extcon is still needed. Thus, you also need extcon in both external-connection and xhci to let this type C work.
Hi @WayneWWW,
Thanks for your help.
The PD controller we have chosen doesn’t need any drivers. It needs USB 3.1 and USB 2.0 lines from SoM is enough and also we are not having any gpio for vbus detection hardware wise. So I am confused about the values need to given to the “extcon-cables” property.
In-order to validate Type-C port, I have did the following exercise.
I have configured it as “host” similar to the 3.1 type-A. I didn’t add any extcon property in this case. Its working in 2.0 mode but USB 3.1 didn’t work.
Could you please give us some suggestions on what should be added for extcon in this case?
Thanks,
Arun
Hi Arun,
You have been filing topics for quite a time. Please keep in mind that if you change anything to your board and make something work while other things not work, please always share the dmseg or related log. We are not engineers who co-work with you so we won’t know everything happens to your board.
Also, for your type C port, you need to tell us how does the pin connection look like. A common type C port should have those CC pin which would control the OTG function. On the devkit, the CC pin state is controlled by the PD controller which has Cypress firmware on it. That is why our driver can use the signal from pd controller and write extcon node in devicetree for driver to use.
I don’t think you just make a type C port without otg function from the beginning, right?
