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:
I’m downloading the kernel source for 28.2, applying the patches to the files in:
…to all locations where it appears in: ./64_TX1/Linux_for_Tegra, though it’s only used in one place.
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.
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:
Patch has been applied to .dts files, .dtb files have been burned to flash, and then extracted and checked on target.
Process has been outlined above for possible identification of errors.
Device is confirmed working on M2 USB port with earlier 2.2.1 JetPack.
Device is confirmed working on a different port on 3.3 JetPack.
VBUS reset after boot has been applied - does not seem to help or cause any syslog output.
Questions:
What’s the best way, beyond extracting the .dts file on the host side, to check that the USB device has been activated properly?
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).
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:
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’.
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:
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).
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.
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:
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.
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:
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?
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.
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?
