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:
I’m downloading the kernel source for 28.2, applying the patches to the files in:
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.
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’.
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.
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:
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…
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?