Enabling USB2-2 on Jetson Nano dts

Autonomous Machines Jetson & Embedded Systems Jetson Nano
#1

Hello everyone,
I’ve been working on a custom board design centered on the Jetson Nano.
So far, most things have worked without issues or I have been able to track them down to some software error (usually dts or some device driver).

Unfortunatelly, I could not find whether I’m missing something with the USB2-2 port, mainly due to the lack of a schematic for the Jetson Nano SoM.
In the absence of such schematic, I am unable to confirm (or discard) if there exists a pin which could be turning off the signal in question.

In conclusion, I would like to confirm if the USB2-2 port should be expected to work out of the box or is expecting the assertion of some internal or external signal (maybe BT_M2_EN or BT_M2_WAKE_AP).

Best Regards,
Juan Pablo.

Port USB 2-2 not working
#3

Hello everyone,
In order to get the best reply possible, I decided to add a little more info.

Our custom board has a USB2514 2.0 hub connected to USB2-1 which is working as expected.
It also has a USB5532B 3.0 hub connected to both USB2-2 and USB3-0 with only the 3.0 part of the hub working as expected.

I’ve already checked the documents available as well as the dts and pieces of the source code.
Since I could not find any issue, I started wondering if I missed something regarding the SoM.

Best Regards,
Juan Pablo.

#4

Hi,
Here are default configuration in

[tegra210-porg-power-tree-p3448-0000-a00.dtsi]
ports {
        usb2-2 {
                vbus-supply = <&p3449_vdd_usb_vbus2>;
        };
};

[tegra210-porg-p3448-common.dtsi]
ports {
        usb2-2 {
                status = "okay";
                mode = "host";
        };
        usb3-0 {
                status = "okay";
                nvidia,usb2-companion = <1>;
        };
};

usb3-0 is paired with usb2-1. You would need to modify to

nvidia,usb2-companion = <2>;

And also inspect if vbus pin is correct.
We have guidance of device tree modification in adaptation guide. Please take a look.

#5

Hi @DaneLLL,
I had already seen those device tree files as well as the document you mention a few times before I asked.

Here you can see a portion of my device tree following your recomendations, so from this I assume USB2-2 should be enabled.

xusb_padctl@7009f000 {
	status = "okay";
	
	ports {
		usb2-0 {
			status = "okay";
			mode = "otg";
			nvidia,usb3-port-fake = <3>;
			vbus-supply = <&p3449_vdd_usb_vbus>;
		};
		usb2-1 {
			status = "okay";
			mode = "host";
			vbus-supply = <&p3449_vdd_usb_hub_en>;
		};
		usb2-2 {
			status = "okay";
			mode = "host";
			vbus-supply = <&p3449_vdd_usb_vbus2>;
		};
		usb3-0 {
			status = "okay";
			nvidia,usb2-companion = <2>;
		};
	};
};

I’m curious that you mention the vbus pin here since both hubs have their VBUS_DET pin wired to 3v3 and this pin should not be required.
If I’m mistaken on that regard, I’d like you to explain more about that.

Best Regards,
Juan Pablo.

#6

In addition to what I said before, the following is currently happening on the software side of things for “usb1-3” (which should be USB2-2):

  • First I see a call to hub_set_address inside “drivers/usb/core/hub.c”.
  • Then hub_set_address proceeds to call xhci_setup_device from “drivers/usb/host/xhci.c”.
  • Finally xhci_setup_device enters the case COMP_TX_ERR and throws the error “Device not responding to setup address”.

I assume this means the port is trying to set the hub address but failing for some reason I don’t know yet.

Best Regards,
Juan Pablo.

#7

Hi @DaneLLL ,
Since I’m still stuck on the same error, I decided to test the pins on USB2-2 in a more direct fashion.
In order to do that, I followed the steps on “Jetson Nano USB2.0 Tuning Guide” and used the “Test J” and “Test K” patterns.
The test patterns allowed me to see if the pins where toggling correctly and measure the voltage levels on them.

I’ve been able to confirm that the pins toggle as expected for both patterns. They also appear to be toggling when the xhci driver attempts to set the hub address.

What I found strange was the voltage level on D+ and D- pins, which was around 1V.
I tried this on 10 different boards, so I’m certain it’s not something specific to one of them.

I would like to confirm whether this is the expected behavior or not.
I also wanted to know if this value is set somewhere on Nvidia’s dts and where would that be.

Best Regards,
Juan Pablo.

#8

Hi,
The device tree files are not for Jetson Nano emmc. Please check

hardware/nvidia/platform/t210b01/porg/kernel-dts/porg-platforms/tegra210b01-porg-fixed-p3448-0001-a01.dtsi

On default board, usb3-0 and usb2-1 are in pair and the regulator is

                vdd_usb_hub_en: regulator@8 {
                        compatible = "regulator-fixed-sync";
                        reg = <8>;
                        regulator-name = "vdd-usb-hub-en";
                        regulator-min-microvolt = <5000000>;
                        regulator-max-microvolt = <5000000>;
                        gpio = <&gpio TEGRA_GPIO(A, 6) 0>;
                        enable-active-high;
                        vin-supply = <&vdd_1v8_com_gate>;
                };

Regulator for usb2-2 is

                vdd_usb_vbus2: regulator@9 {
                        compatible = "regulator-fixed";
                        reg = <9>;
                        regulator-name = "vdd-usb-vbus2";
                        regulator-min-microvolt = <5000000>;
                        regulator-max-microvolt = <5000000>;
                        vin-supply = <&vdd_3v3_sys>;
                };

Please check if you have different design on the custom board. If you also has a GPIO pin in enabling hub, need to modify the regulator accordingly.

#9

Hi @DaneLLL,
The file you mention “hardware/nvidia/platform/t210b01/porg/kernel-dts/porg-platforms/tegra210b01-porg-fixed-p3448-0001-a01.dtsi” does not exist.

From what I have seen (and I’ve seen a lot of dts files on Jetpack 32.1, 32.3.1 and 32.4.2 sources) the files for all iterations of Jetson Nano Devkits have the form tegra210-p3448-0000-p3449-0000-xxx.dts or tegra210-p3448-0002-p3449-0000-xxx.dts so far. All those files include a gpio dts file, a pinmux dts file and tegra210-porg-p3448-common.dtsi.
One would assume that tegra210-porg-p3448-common.dtsi has the common parts for p3348 SoM. Further inspection shows it also includes some includes for p3349 devkits in the form of overlays (some of those get enabled based on the som model when they should be enabled based on the devit model).

In my custom board, the working hub has DP connected to pin 117 and DM pin connected directly to pin 115. This hub has the VBUS_DET pin connected to 3V3, leaving it enabled.
In a similar fashion, the broken hub has DP connected to pin 123 and DM pin connected directly to pin 121. This hub also has the VBUS_DET pin connected to 3V3, leaving it enabled.

To take things one step further, the team decided to completely remove the hub and plug pins 123 and 121 directly to a pendrive. The pendrive was also connected directly to the main (5V) power supply.

pendrive-connection

Under the previously mentioned conditions, the pendrive did not work at all.
We have already confirmed this unit to be working on port 0 with a similar configuration.
From this test it seems like the Jetson Nano Module does not detect changes on the data lines at all.

Best Regards,
Juan Pablo

#10

Hi,
One possible cause is that VBUS may be on too early. We have seen similar issues in enumeration:


Please do hardware reset after booting to kernel. See if it triggers enumeration.

#12

Hi @DaneLLL,
Since my current line of thought seems to be taking me nowhere, I’ll try a different approach.

So far, every step involving the pull-ups and pull-downs for usb port 2-2 seem to be working (at least when the system boots).
I have checked with an oscilloscope what seems to be the device connection, detection and enumeration exchange.

First, I would like to confirm whether this hypothesis is true.
I think the “new full-speed USB device number %d using tegra-xusb” should do fine.
However, I would still like to know if there are any additional checks I can perform from the software side.

Second, assuming my previous hypothesis is correct, I would like to know how to confirm with 100% certainty that the Nano is properly configuring and enabling the HS Driver and Receiver.
In order to do that, I would appreciate if you could list all the steps you consider necessary, whether it be reading logs, checking /proc or /sys, reading system memory with devmem or anything else.

Best Regards,
Juan Pablo.

#13

Hi,

Please directly share the schematic, current dmesg and dts.

#14

Hi @WayneWWW, @DaneLLL,
Thanks for your patience so far.
I finally found the error and it was indeed a software error.
Or maybe, it would be more accurate to say it was a firmware error.

For some reason, the file tegra210b01_xusb_firmware got renamed to tegra21x_xusb_firmware and then it was placed in a folder where it would overwrite the real tegra21x_xusb_firmware every single time.
Since it seems like tegra210b01 shares many similarities with the soc on the nano, most usb ports worked fine, with the exception of usb2-2.

In the future, in addition to suggesting it might be a dts error, you can also direct people to check if they got the firmware files from whatever place you consider to be most reliable.

Best Regards,
Juan Pablo.

#15

Hi,
Thanks for reporting the issue. We will investigate on it.

#16

Hi,

Actually, I would prefer you to sharing the dmesg instead of current debug method. We didn’t meet such firmware problem before.

#17

Hi,
We have checked and the correct path of the firmware is

/lib/firmware/tegra21x_xusb_firmware

We don’t see firmware being named tegra210b01_xusb_firmware. Not sure why you get the firmware.

Since you have make it work, we should be good now. Please feel free to start a new post if you have further queries. Thanks.

#18

Hi @WayneWWW, @DaneLLL,
Maybe I didn’t express myself as clearly as I thought. The firmware on Nvidia’s side is fine.

Since I use a custom build based on buildroot, I had the wrong file at the right place (the xusb firmware file for tegra210b01 was replacing the firmware file for the Nano).
What I tried suggesting was that, should someone else run into a similar issue, they could be using an incorrect firmware file like I did.

Best Regards,
Juan Pablo.

#19

Hi,
We shall have removed tegra210b01_xusb_firmware from r32.3.1. Not sure but you probably use previous version. My apology for the confusion.