Patch for enabling USB3 on M2 slot using latest JetPack 3.2.1

I have followed the documentation for building DTB files using the kernel’s Makefile with patches from forum post below implemented:

https://devtalk.nvidia.com/default/topic/1023046/jetson-tx1/unable-to-recognize-any-devices-hooked-on-usb2-m-2-slot-/1

I’ve triple checked that the patches were applied properly.

I have then burned the new .dtb files:

  • tegra210-jetson-cv-base-p2597-2180-a00.dtb &&
  • tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb

…using script:
sudo ./flash -r -k DTB -d <above_files> jetson-tx1 mmcblk0p1

I then copied them over to the /boot directory as mentioned in the 3.2.1 documentation. I have also copied over the new kernel.

I am still unable to recognize devices on the port.

Questions:

  1. What am I doing wrong?
  2. Is the patch in the link above still valid for 3.2.1?
  3. If not, is there a new patch along with a comprehensive outline for applying it?

Thank you. We’re in the final stages of product release and production is waiting on this and a few other last steps.

Regards,

Mumi

Beware that the version in “/boot” is no longer used. Any extlinux.conf FDT entry will not do what you expect.

There is also a patch which might still apply for R28.2.1 (this was originally for R28.2):
https://devtalk.nvidia.com/default/topic/1036286/jetson-tx1/flashing-just-dtb-on-28-2-and-tx1/post/5264465/#5264465

To know if your device tree patch actually worked you should extract the running system’s device tree for comparison:

dtc -I fs -O dts -o extracted.dts /proc/device-tree

FYI, I know nothing about the particular patch for M.2.

Please check if the VBUS is on after booting to kernel:
https://devtalk.nvidia.com/default/topic/1036547/jetson-tx1/usb2-b43-b42-not-working-on-tx1-with-r28-2/post/5265708/#5265708

@linuxdev @DaneLLL

General:

I’ve extracted the .dts from /proc/device-tree as mentioned above, and I do see the device additions that I’ve made via the patch - so the .dtb has applied properly. The .dtsi has been checked multiple times for any omitted data, and there’s nothing missing.

For a sanity check, I loaded JetPack build 2.2.1 - which has a known active USB port on M2 by default, and my Device was enumerated properly. This was tested on the exact same hardware.

For an additional sanity check, I reloaded Jetpack 3.3 with the patch applied. I then plugged our device (a Telit modem) into another USB port, and it enumerated properly. But still no luck on the M2 port’s USB…

Just to make sure I’m doing things properly, let me outline my process:

Steps:

  1. I’m downloading the kernel source for 28.2, applying the patches to the files in:

    /usr/src/hardware/nvidia/platform/t210/jetson/kernel-dts

  2. I then copy the .dtb file listed in jetson-tx1.conf:

    DTB_FILE=tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb

    …to all locations where it appears in: ./64_TX1/Linux_for_Tegra, though it’s only used in one place.

  3. Then I tried both burning the DTB files only (with the edit required for the flash.sh script), and via complete burn from JetPack gui.

  4. Then I check by extracting the .dts using the dtc command above, and confirmed that the usb3 additions are in place.

VBUS:

In order to rule out VBUS as a possible issue, I reset the VBUS pin manually (electrically) on our PCB well after boot, and several times. This did not cause the device to enumerate.

I’ve monitored syslog during a plug/unplug of the device and there’s no activity when the device is connected/disconnected.

Recap:

  1. Patch has been applied to .dts files, .dtb files have been burned to flash, and then extracted and checked on target.
  2. Process has been outlined above for possible identification of errors.
  3. Device is confirmed working on M2 USB port with earlier 2.2.1 JetPack.
  4. Device is confirmed working on a different port on 3.3 JetPack.
  5. VBUS reset after boot has been applied - does not seem to help or cause any syslog output.

Questions:

  1. What’s the best way, beyond extracting the .dts file on the host side, to check that the USB device has been activated properly?
  2. Are we certain that the same patch should work with 3.2, as it does with 3.1 (I have not tested it on 3.1).
  3. What else can I try?

Hi mumi1048576,
We have verified the patch on Jetpack 3.1. Please try Jetpack 3.1 to see if the issue you are facing is specific to Jetpack 3.3.

Hi @DaneLLL,

Testing the patch on JetPack 3.1 actually enabled the USB port properly.

So it seems that the patch does not work on JetPack 3.2-3.3.

We’re now faced with the issue, in that we require support from the JetPack 3.2-3.3 and r28.2 kernel, in the form of latest CUDA/Tensor software + drivers for our Nimbelink GELS3 LTE CAT1 modem.

Question:

  1. Could there possibly be a quick turn fix for the patch, so that it can be applied to JetPack 3.2-3-3?

Just to clarify further, there is no usb-related syslog activity at all when a device is plugged into the M2 USB port with this patch applied to JetPack 3.2-3-3. There is also no additional device listed via ‘lsusb’.

Regards,

Mark

Hi Mark,
On r28.2, can you ensure usb3-port-fake is 3?

usb2-micro-AB-xusb {
				nvidia,lanes = "otg-0";
				nvidia,function = "xusb";
				nvidia,port-cap =
					<TEGRA_PADCTL_PORT_OTG_CAP>;
				<b>nvidia,usb3-port-fake = <3>;</b>
			};

In the patch , it has

@@ -505,7 +505,7 @@
 				nvidia,function = "xusb";
 				nvidia,port-cap =
 					<TEGRA_PADCTL_PORT_OTG_CAP>;
[b]-				nvidia,usb3-port-fake = <2>;
+				nvidia,usb3-port-fake = <3>;[/b]
 			};
 			usb2-std-A-port0 {
 				 nvidia,lanes = "otg-2";

It is not required for r28.2 because it is 3 already.

Hi @DaneLLL,

Yes, I have fully applied the patch in the .dts files when using them to build .dtb files for 3.2. So I have set: usb3-port-fake is 3 in the .dts file. Is that what you mean?

Here’s that section from my .dts file used to create the .dtb on 3.2:

cat tegra210-jetson-cv-base-p2597-2180-a00.dts | grep -A3 -B5 usb3-port-fake
			usb2-micro-AB-xusb {
				nvidia,lanes = "otg-0";
				nvidia,function = "xusb";
				nvidia,port-cap =
					<TEGRA_PADCTL_PORT_OTG_CAP>;
				nvidia,usb3-port-fake = <3>;
			};
			usb2-std-A-port0 {
				 nvidia,lanes = "otg-2";

Hi Mark,
nvidia\platform\t210\jetson\kernel-dts\jetson-platforms\tegra210-comms-p2530-0930.dtsi

wlan-default-output-high {
			gpio-hog;
			output-high;
			gpios = <
				TEGRA_GPIO(H, 0) 0
				TEGRA_GPIO(I, 0) 0
				<b>TEGRA_GPIO(I, 2) 0</b>
				>;
			label = "wlan-default-output-high-h0",
				"wlan-default-output-high-i0";
		};

Please remove the bold line and try again.

@DaneLLL,

I have applied this change and the outcome is the same, no luck enumerating the device.

Was the last proposed change related to the fact that our device is a modem? The issue definitely seems to be at much lower layers than even device type recognition - where plugging in the USB device does not cause any activity in syslog.

How are the wlan changes related to enabling the USB port? I noticed some wlan default output changes in the: tegra210-comms-p2530-0930.dtsi for the original patch (which I have fully applied for test).

Regards,

Mark

@DaneLLL,

I’ve uncovered a partial clue via some testing.

As a quick test, I decided to run 3.1’s patched (and functional) .dtb file: tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb on JetPack 3.2.1. I assumed that this wouldn’t run, but that I might at least see a device enumeration at boot.

This in fact was the case! With 3.1’s patched .dtb file, the 3.2 kernel recognizes our modem and enumerates it properly as a ttyACM0 serial device at boot!

[   12.381871] IPVS: Creating netns size=1424 id=1
[   12.478094] l4tbr0: port 2(usb1) entered disabled state
[   12.750224] usb 1-4: new high-speed USB device number 3 using xhci-tegra
[   12.775713] usb 1-4: feature bit otg_vbus_off set
[   12.781239] usb 1-4: New USB device found, idVendor=1e2d, idProduct=00a0
[   12.789040] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   12.802489] usb 1-4: Product: SQN
[   12.808139] usb 1-4: Manufacturer: Sequans Communications
[   12.814608] usb 1-4: SerialNumber: 706338728002
[   12.828604] cdc_ether 1-4:1.0 usb2: register 'cdc_ether' at usb-70090000.xusb-4, CDC Ethernet Device, 02:80:72:38:63:70
[   12.843138] cdc_acm 1-4:1.2: ttyACM0: USB ACM device

Then the system crashes.

Before this test I began diffing the .dts(i) files between 3.1 and 3.2. There are many differences, but I’m working toward locating the breaking change for USB between 3.1 and 3.2.

Assistance in locating the breaking change would save us lots of searching/testing.

Regards,

Mark

We have verified the attached patch. Pleas give it a try.
0001-r28.2-DNI-dts-tegra210-jetson-enable-usb-on-E3325.patch.txt (2.97 KB)

@DaneLL,

I tested this patch with a fresh install of JetPack 3.3 (L4T 28.2). I had no luck. Below is an outline of how I applied the patch.

Basic Steps:

  1. Install JetPack3.3.
  2. Load OS and drivers + Flash system.
  3. Pull kernel sources down on target.
  4. Extract .dtb file before flashing patched dtb, for comparison, via:
    dtc -I fs -O dts -o extracted.dts /proc/device-tree5. Replace .dtb pointed to by: jetson-tx1.conf
  5. Perform flash script edit mentioned here:
    https://devtalk.nvidia.com/default/topic/1036286/jetson-tx1/flashing-just-dtb-on-28-2-and-tx1/post/5264465/#5264465
  6. Flash via: sudo ./flash.sh -k DTB jetson-tx1 mmcblk1p1
  7. Extract .dtb file after flashing patch.
  8. Diff files and recognize that the patch has been applied.
  9. Check for modem enumeration via lsusb (which shows proper enumeration using JetPack 3.1 with previous patch applied).
  10. Recognize that the device has not been enumerated.

Linked Files List:
I have included all of my relevant files in device_tree_files.tar.gz at link below for inspection:

  • extracted-beforepatch.dts - Extracted .dts before patching
  • extracted-afterpatch.dts - Extracted .dts after patching
  • tegra210-comms-p2530-0930.dtsi - Source file with patch applied
  • tegra210-jetson-cv-base-p2597-2180-a00.dts - Source file with patch applied
  • tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb - Compiled patched device tree

My Files:
https://drive.google.com/file/d/1kCG0mHrgq0K0NNAKJhHQdEIkYAp5EbQy/view?usp=sharing

Would it be possible to send along your pre-compiled .dtb file for testing on my side?

Regards,

Mark

Hi Mark,
Can you try below steps:

  1. Copy tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb to /Linux_for_Tegra/kernel/dtb/
  2. Flash JetPack-3.2.1 (r28.2) on TX1
  3. After bootup, check USB function from dmesg.

@DaneLLL,

Those steps are exactly what I have tried, with the only difference being JetPack-3.3. But JetPack-3.2.1 shares the same L4T 3.2 build, as confirmed in the archive:

https://developer.nvidia.com/embedded/jetpack-archive

However, I just tried the proposed steps using JetPack-3.2.1 and there’s still no enumeration of the device.

But I am seeing USB differences in boot and dmesg output of the patched and unpacked L4T 3.2 build, shown below:

Unpatched on left, vs. Patched on right:

However, I’m still unable to make a device enumerate when plugged into the port - the same that will enumerate properly on the dev board’s USB A connector (whether patched or unpatched).

lsusb -t on the patched vs. unpatched system yields the same results.

Linked Files List:
I have included the dmesg and boot logs from a system running the patched and unpatched (original JetPack-3.2.1) .dtb files.

  • boot_nopatch.txt - system boot with original .dtb files.
  • boot_patch.txt - system boot with patched .dtb files.
  • dmesg_nopatch.txt - dmesg output with original .dtb files.
  • dmesg_patch.txt - dmesg output with patched .dtb files.

My Files:
https://drive.google.com/open?id=1LOUpu9_Rx5TqYLQ0nOxoEyKawQakyAu7

Questions:

  1. Were you able to enumerate a device with this USB solution?
  2. If so, would you be able to send along your pre-compiled .dtb file for test on our side?

Hi Mark,
Please try the attached DTB. We have verified it on r28.2/TX1/default carrier board.
r282-1562220-tegra210-jetson-tx1-p2597-2180-a01-devkit.zip (58.1 KB)

@DaneLLL

*** UPDATE ***

I have previously stated that your .dtb was working for us. This was a mistake on my side. It is not working - I just had a second device plugged into the board’s regular USB A connector. I have updated my response below.

*** END UPDATE ***

When extracting the .dtb files on the system when running my patched .dtb vs. yours, I’m not seeing anything different outside of changes in dram clock and trim registers.

But I am seeing one difference that is interesting…

My .dtb on the left shows a different root partition mmcblk1p1 vs your mmcblk0p1, shown below:

… but this is interesting, because mmcblk1p1 lines up with what is APPENDed to the bootargs in the sdcard conf file (rather than emmc), contents:

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk1p1 rw rootwait

However, none of the differences seem to resolve the issue.

Questions:

  1. Could something related to the bootargs be causing our issue? How would these be different for our different .dtb files? The appended data comes from the same .conf file in both cases, right?
  2. Have you tested your solution using USB hardware connected to the M2 port to make sure that it enumerates properly?

Linked Files List:
I am including extracted .dts files from a system running my latest patch and your patch.

  • extracted_non-nvidia.dts - extracted .dts running my patched .dtb.
  • extracted_nvidia.dts - extracted .dts running your patched .dtb.

My Files:
https://drive.google.com/drive/folders/1AZ-hwHFnZwOJYBC0EVYbCbQ9YLoWHlp4?usp=sharing

You might compare the content of “/proc/cmdline” under both, this will reflect the final APPEND.

For default carrier board, the correct one should be mmcblk0p1. So you follow the guidance/steps and build the DTB with wrong mmcblk1p1?

Yes.

Now it’s a bit strange that we’re both seeing different results with hardware we’ve tested, especially since the same hardware is recognized when we apply the earlier patch to L4T 28.1…

Questions:

  • I took a quick measurement of what should be VBUS, and I'm only seeing 0.7Volts. It seems like a bus voltage may be left low in the patch applied to 28.2 vs the patch applied to 28.1. Does this make sense based on your knowledge of the patch and new kernel? And would you be able to help with livening this up?
  • Can you tell us what type of device you've tested, if it was externally powered, and exactly how you went about testing it on your system?

Thank you again.

Mark