Attached you can find the modified device tree.
- We have USB0 as micro USB Type AB and 2x USB3.0 Type A (exactly config #3)
- PCIe works so far.
modified_dt.zip (58 KB)
Hi sevm89,
May I ask why you disabled port 3-2?
usb3-0 {
status = "disabled";
};
usb3-1 {
status = "okay";
nvidia,usb2-companion = <0x1>;
};
usb3-2 {
status = "disabled";
Could you also share the full boot log? Please remember to connect some usb device on port during test.
Hi WayneWWW
We started from the dtsi file “tegra186-quill-p3310-1000-c03-00-dsi-dp.dts” from within the sources of Jetpack 4.2. We then changed the file “tegra186-quill-p3310-100-c03-00-base.dts” according to the description of [url]https://elinux.org/Jetson/TX2_USB[/url] and also the other mentioned files (plugin manager and power-tree). We are not sure why usb3-2 is disabled, we will check again all the included dts files.
The DTB we build within the kernel sources.
The boot log is attached.
Thank you.
boot_log.txt (81.3 KB)
Hi sevm89,
Is everything good now? Any result can be shared?
Thanks
Hi kayccc
It is still not working.
Could you see something from the boot log? Are we doing something wrongly when building the dtb?
Thank you.
I checked your device tree again and there is something wrong. All the guidance on the elinux page is for rel-28. Jetpack4.2 is for rel-32 which uses k4.9. But the idea is basically the same.
Could you check your device tree and change it back to default first?
Please note that for jetpack4.2, only those with
#if TEGRA_XUSB_PADCONTROL_VERSION >= DT_VERSION_2 would be used.
So there is no “utmi-1” or “utmi-2” anymore.
Hi WayneWWW
Does that mean that changing utmi-1 and utmi-2 like this is all we have to do?
phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-0}>,
<&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-1}>,
<&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-2}>,
<&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-0}>,
<&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-1}>,;
phy-names = "usb2-0", "usb2-1", "usb2-2", "usb3-0", "usb3-1";
};
There is also no utmi-0, right?
We change the following:
utmi-0 to usb2-0
utmi-1 to usb2-1
utmi-2 to usb3-0
Thank you.
Yes, no utmi-* anymore.
Thanks Wayne,
It worked.
Regards
Hi WayneWWW
We made some progress with the topic with now the JetPack 4.2.1. Attached you can find our device tree. So far everything except of USB3-2 is working. We use the config #3 of the USB/PCI Lane Mapping.
Is there something wrong in the device tree? The USB2 corresponding to the USB3-2 goes over a hub. Therefore we put as companion attribute the port that goes to the hub.
What we also still see while booting is the following error:
[ 8.718830] sdhci-tegra 3440000.sdhci: could not set regulator OCR (-1)
[ 8.727824] vdd-1v8: voltage operation not allowed
We need to change something?
Thank you for your help.
Kind regards
devicetree.zip (54.3 KB)
Hi,
- No worry for below issue. It is not fatal and you could see them on devkit too.
[ 8.718830] sdhci-tegra 3440000.sdhci: could not set regulator OCR (-1)
[ 8.727824] vdd-1v8: voltage operation not allowed
-
To use config 3 of PCIe/USB mapping, you need to set pcie num-lane to 2 but the ODM data to 0x6090000.
-
You could remove “pinctrl@3520000” in your device tree. rel-32 does not use this anymore. That was my point in # 46.
-
What is 0x26 in vbus-supply? Is this the dummy regulator as battery_reg?
I am confused by your description " The USB2 corresponding to the USB3-2 goes over a hub. Therefore we put as companion attribute the port that goes to the hub.".
What do you mean there is a hub?
If this is config 3, there should be a USB_SS#0,1,2. (and you disable one port) The design logic behind all these 3 ports should be same. You need have one usb2 pin to accompany with a usb3 pin. Is this pin usb3-2 using different hardware design?
BTW, could you also share a diff of what you’ve modified for usb part?
Hi
-
OK, we will ignore this.
-
ODM data is set to 0x6090000. pcie0_lan2_mux is set to “okay”. Do you mean that?
-
Ok, we can remove this part.
-
Yes, this is the battery_reg.
For two USB3 Ports, we use USB_SS#1 (PEX_RFU) and USB_SS#2. The accompanying USB2 pins for the signals PEX_RFU are going over a hub on our custom board (USB2.0 Hub). (This worked with JetPack3.3) I don’t think this is a problem.
Here our modifications:
xhci@3530000 {
phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-0}>,
<&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-1}>,
<&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-2}>,
<&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-1}>,
<&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-2}>;
phy-names = "usb2-0", "usb2-1", "usb2-2", "usb3-1", "usb3-2";
};
xusb_padctl@3520000 {
status = "okay";
pinctrl-0 = <&vbus_en0_default_state>;
pinctrl-1 = <&vbus_en1_default_state>;
pinctrl-2 = <&vbus_en0_sfio_tristate_state>;
pinctrl-3 = <&vbus_en1_sfio_tristate_state>;
pinctrl-4 = <&vbus_en0_sfio_passthrough_state>;
pinctrl-5 = <&vbus_en1_sfio_passthrough_state>;
pinctrl-names = "vbus_en0_default", "vbus_en1_default",
"vbus_en0_sfio_tristate", "vbus_en1_sfio_tristate",
"vbus_en0_sfio_passthrough", "vbus_en1_sfio_passthrough";
pads {
usb2 {
lanes {
usb2-0 {
nvidia,function = "xusb";
status = "okay";
};
usb2-1 {
nvidia,function = "xusb";
status = "okay";
};
usb2-2 {
nvidia,function = "xusb";
status = "okay";
};
};
};
usb3 {
lanes {
usb3-0 {
nvidia,function = "xusb";
status = "disabled";
};
usb3-1 {
nvidia,function = "xusb";
status = "okay";
};
usb3-2 {
nvidia,function = "xusb";
status = "okay";
};
};
};
};
ports {
usb2-0 {
status = "okay";
mode = "otg";
vbus-supply = <&vdd_usb0_5v>;
nvidia,oc-pin = <0>;
};
usb2-1 {
status = "okay";
mode = "host";
vbus-supply = <&vdd_usb1_5v>;
nvidia,oc-pin = <1>;
};
usb2-2 {
status = "okay";
mode = "host";
vbus-supply = <&battery_reg>;
};
usb3-0 {
status = "disabled";
};
usb3-1 {
nvidia,usb2-companion = <1>;
status = "okay";
};
usb3-2 {
nvidia,usb2-companion = <2>;
status = "okay";
};
};
};
gpio@2200000 {
sdmmc-wake-support-input {
status = "okay";
};
sdmmc-wake-support-output {
status = "okay";
};
pcie0_lane2_mux {
status = "okay"; //This is for switch from usb3.0 to x1 PCIe on M.2.
};
};
Thank you.
If usb3-2 and usb3-1 share the same design and usb3-1 can work, then I would think battery_reg is the cause of the problem.
We also have such problems from other forum users too. The only suggestion here is to find another gpio to act as a regulator.
If any working case is using battery_reg, honestly speaking, it is probably just coincidence. W/O driver to control the timing, the behavior is unpredictable.
Is that why we see kernel panics when a usb2.0 device is already connected at the boot process? On the same port, a usb3.0 is never recognized.
Our used hub is always-on. Does that mean this needs a change of schematic? If not, could you explain how we use another gpio to act as a regulator?
Yes, you need a change for your schematics.
Please refer to this topic. The cause of your issue is the same as this one.
Hi WayneWWW
Is it enough to activate the USB2.0 Hub we use for the not working USB3.0 port with a GPIO during the boot process? For understanding, the USB2.0 signals of one of our USB3.0 Interfaces goes over a hub on our carrier board.
Thank you.
I am not sure about your problem here. Do you mean you just want to enable the USB2.0 hub but not 3.0 port ?
Hi WayneWWW
Attached the bloc diagram of our USB circuit for your understanding. As you can see, the USB2.0 Signals of one of our USB3.0 Ports go over a hub. In the current design, the Hub is always-on as soon as the Jetson TX2 Module turns on. We guess that this can be a problem why now we would use a GPIO of the TX2 Module to turn the hub on. Is this correct or do we need to consider something else?
Thanks.
Could you also share your latest dmesg with us? This issue has been a while…
