Hi, I’m now using a carrier board as a platform to validate some hardware functions. When using 2 thin cables to pin out USB2 D+/D- from M.2 slot, and powering using USB3.0(VBUS, GND), nothing shows up(tried mouse and USB thumb drive). Is there anything else should be connected?
Cable is good BTW.
I don’t know which changes to make, but it is very likely a device tree edit would do the job. This might depend on which L4T version you use, you might mention if R21.5, so on (see “head -n 1 /etc/nv_tegra_release” to check).
EDIT: Oops…R21.5 is TK1, I meant whether R28.1 or an earlier release, but this is answered as R28.1 in the next post. It’s just that I mistook M.2 on the TX1 for the mini-PCIe on TK1 (mini-PCIe also has a D+/D- line).
Hi Linuxdev,
You may find the info below.
And the Power actually is from microUSB port. Measured with multimeter and got a 5V so might not be the power issue.
Hi KitKatY,
Which device are you using on M.2 slot?
Hi Carouyuu,
I’m now using the original carrier board.
There is an interesting discovery also, tx2 module seems working perfectly with such configuration.
I hope can make onboard USB2 to work with Axis AX88178A which is a network adapter in my further design.
Hi KitKatY,
Do you see any error in boot log. It would be great if you can share the log of r28.1 on TX1 and TX2 for comparison.
Not exactly…And actually, I had been waiting for another TX1 to check whether there were hardware issues.
Two TX1 act the same in this case.
You may find out the syslog below. Hope it is not so troublesome.
Thanks for your kindness.
Syslog.zip (66.3 KB)
For r28.1/TX1, please try the patch attached.
0001-DNI-dts-tegra210-jetson-enable-usb-on-E3325.patch.txt (3.11 KB)
Hi KitKatY,
Have you tried the patch?
Any result can be shared?
Thanks
Hi DaneLLL/Kayccc,
I am also facing the same problem and tried the above shared patch. Now it could able to recognise the device on the USB2. I connected sierra modem as a device. I have one problem that, eventhough device detected i observed some crash. Please see the below prints.
[ 18.136668] usb 1-4: new high-speed USB device number 2 using xhci-tegra
[ 18.167610] usb 1-4: config 1 has an invalid interface number: 8 but max is 7
[ 18.174962] usb 1-4: config 1 has an invalid interface number: 19 but max is 7
[ 18.182512] usb 1-4: config 1 has an invalid interface number: 20 but max is 7
[ 18.190568] usb 1-4: config 1 has an invalid interface number: 20 but max is 7
[ 18.198064] usb 1-4: config 1 has no interface number 1
[ 18.203919] usb 1-4: config 1 has no interface number 6
[ 18.209211] usb 1-4: config 1 has no interface number 7
[ 18.215513] usb 1-4: New USB device found, idVendor=1199, idProduct=68c0
[ 18.222326] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 18.229544] usb 1-4: Product: WP7504
[ 18.233635] usb 1-4: Manufacturer: Sierra Wireless, Incorporated
[ 18.239658] usb 1-4: SerialNumber: 0123456789ABCDEF
[ 18.258052] Calling GobiUSBNetProbe@2275
[ 18.262371] Calling GobiProbe@593
[ 18.267682] GobiSerial 1-4:1.0: GobiSerial converter detected
[ 18.274187] usb 1-4: GobiSerial converter now attached to ttyUSB0
[ 18.280575] Calling GobiUSBNetProbe@2275
[ 18.284876] Calling GobiProbe@593
[ 18.289725] GobiSerial 1-4:1.2: GobiSerial converter detected
[ 18.295987] usb 1-4: GobiSerial converter now attached to ttyUSB1
[ 18.302285] Calling GobiUSBNetProbe@2275
[ 18.306468] Calling GobiProbe@593
[ 18.311439] GobiSerial 1-4:1.3: GobiSerial converter detected
[ 18.317565] usb 1-4: GobiSerial converter now attached to ttyUSB2
[ 18.323933] Calling GobiUSBNetProbe@2275
[ 18.329401] Calling GobiProbe@593
[ 18.336846] GobiSerial 1-4:1.4: GobiSerial converter detected
[ 18.349173] usb 1-4: GobiSerial converter now attached to ttyUSB3
[ 18.355675] Calling GobiUSBNetProbe@2275
[ 18.359686] Calling GobiProbe@593
[ 18.363280] Calling GobiUSBNetProbe@2275
[ 18.369122] GobiNet 1-4:1.8 eth1: register ‘GobiNet’ at usb-70090000.xusb-4, GobiNet Ethernet Device, fe:6a:e9:f6:e0:95
[ 18.380907] USB Speed : USB 2.0
[ 18.384110] do not call blocking ops when !TASK_RUNNING; state=1 set at [] QMIReady+0x114/0x514
[ 18.386337] cdc_ether 1-4:1.19 usb0: register ‘cdc_ether’ at usb-70090000.xusb-4, CDC Ethernet Device, e2:76:d0:76:de:00
[ 18.405900] ------------[ cut here ]------------
[ 18.410514] WARNING: at …/kernel/sched/core.c:7614
[ 18.415382] Modules linked in: ads7924 bcmdhd bluedroid_pm
[ 18.420888]
[ 18.422376] CPU: 3 PID: 1403 Comm: GobiNetThread:0 Not tainted 4.4.38+ #12
[ 18.429232] Hardware name: jetson_tx1 (DT)
[ 18.433317] task: ffffffc0e3a34b00 ti: ffffffc0e66f8000 task.ti: ffffffc0e66f8000
[ 18.440786] PC is at __might_sleep+0x50/0x94
[ 18.445045] LR is at __might_sleep+0x50/0x94
[ 18.449302] pc : [] lr : [] pstate: 80000145
[ 18.456679] sp : ffffffc0e66fbbb0
[ 18.459981] x29: ffffffc0e66fbbb0 x28: 0000000000000000
[ 18.465293] x27: 0000000000000000 x26: 0000000000000000
[ 18.470603] x25: 000000000000000c [ 18.471810] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 18.472348] GobiNet 1-4:1.8 eth1: kevent 12 may have been dropped
[ 18.472357] GobiNet 1-4:1.8 eth1: kevent 12 may have been dropped
[ 18.472816] GobiNet 1-4:1.8 eth1: kevent 12 may have been dropped
[ 18.497858] x24: ffffffc0006f31e4
[ 18.501435] x23: ffffffc0dea1ef00 x22: ffffffc0dea1ef00
[ 18.506744] x21: 0000000000000000 x20: 00000000000003bb
[ 18.512054] x19: ffffffc001039db0 x18: 0000000000004100
[ 18.517366] x17: 0000007fb1d21f18 x16: ffffffc0001d6fa8
[ 18.522678] x15: 003b9aca00000000 x14: 0005938381000000
[ 18.527990] x13: ffffffffa8d3d1cb x12: 0000000000000018
[ 18.533301] x11: 0000000017b6c4fd x10: 0000000000000860
[ 18.538612] x9 : ffffffc0e66fb9b0 x8 : ffffffc0e3a353c0
[ 18.543923] x7 : 0011e1a2fc122400 x6 : 000000000476971d
[ 18.549235] x5 : 0000000000000001 x4 : ffffffc0f62ea1d0
[ 18.554547] x3 : ffffffc0014fcaf8 x2 : 0000000000000000
[ 18.559857] x1 : ffffffc0e66f8000 x0 : 0000000000000065
[ 18.565168]
[ 18.566652] —[ end trace f266956a5ce6dc97 ]—
[ 18.571255] Call trace:
[ 18.573695] [] __might_sleep+0x50/0x94
[ 18.578994] [] __pm_runtime_resume+0x38/0x94
[ 18.584814] [] usb_autopm_get_interface+0x24/0x6c
[ 18.591065] [] WriteSync+0xd0/0x4b0
[ 18.596103] [] QMIReady+0x1d0/0x514
[ 18.601141] [] RegisterQMIDevice+0x1b0/0x664
[ 18.606960] [] thread_function+0xa4/0x210
[ 18.612519] [] kthread+0x100/0x108
[ 18.617470] [] ret_from_fork+0x10/0x40
[ 18.624739] GobiNet 1-4:1.8 eth1: kevent 12 may have been dropped
[ 18.644940] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
[ 18.651397] cdc_ether 1-4:1.19 usb0: kevent 12 may have been dropped
[ 20.070160] TE Flow Control disabled
[ 20.358251] creating qcqmi0
[ 20.362632] Ethernet mode
[ 22.060609] CFGP2P-ERROR) wl_cfgp2p_add_p2p_disc_if : P2P interface registered
[ 22.093392] WLC_E_IF: NO_IF set, event Ignored
Could you please help why i am getting crash.
Thanks
Hi DaneLLL,
I observed one more thing that, when Modem device detects
R24.2.1: “ifconfig” shows like below
enx00044b65d5e6 Link encap:Ethernet HWaddr 00:04:4b:65:d5:e6
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr 32:a4:f7:42:dc:33
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
R28.1: “Ifconfig” shows
eth0 Link encap:Ethernet HWaddr 00:04:4b:66:43:c1
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth1 Link encap:Ethernet HWaddr fe:6a:e9:f6:e0:95
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:8 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Is this expected?
Just FYI, “enx00044b65d5e6” is a naming convention which implies udev renamed the device, whereas the “eth0” or “eth1” naming is the original device name without a udev rename. Both are valid, but if a program hard coded the naming convention instead of detecting the correct port name there would be a problem. Mostly it isn’t a problem.
The fact that the devices show up under ifconfig means mostly things are working as expected, though the kernel register dump says not everything is correct. It is possible the GobiNet driver only functions correctly after a firmware load custom to the device is complete, but I’m just speculating. If you research the requirements for this device there may be an indication of requirements other than just the driver.
Is this driver something you compiled, or perhaps which was provided by a manufacturer?
Please check your HW design per https://developer.nvidia.com/embedded/dlc/jetson-tx2-oem-product-designguide
The note in the doc probably helps
Note:
1. Common mode filters on USB[2:0]_DP/DN (USB 2.0 interfaces) are optional. Place only as needed if EMI is an issue. Common mode filters on USB3_TX/RX_P/N signals are not recommended. If common mode devices are placed, they must be selected to minimize the impact to signal quality, which must meet the USB spec. signal requirements. See the Common Mode Choke requirements in the USB 3.0 Interface Signal Routing Requirements table.
2. If USB 3.0 is routed to a connector, only AC caps on Jetson TX2 TX lines are required. If routed directly to a peripheral, AC caps are needed for both Jetson TX2 TX lines (connected to device RX) & Device TX lines (connected to Jetson TX2 RX).
3. USB0 must be available to use as USB Device for USB Recovery Mode.
4. Connector used must be USB-IF certified if USB 3.0 implemented.
Hi Linuxdev,
Thanks for the detailed answer. We got the driver from the manufacturer. I will try to connect to the LTE network and share my observations.
@DaneLLL - We are using the R28.1 for TX1, not for TX2. In TX1 for R24.2.1 “all USB2 devices worked directly with the base software”, whereas for R28.1 USB2 devices not able to detect.
After applying the patch file, then only It could able to detect the device. I am not sure why kernel panic happening, even though the driver is working one without any issues (verified in R24.2.1).
Is it something related to DT patch that I applied? Anyway I will check the driver related to this crash.
Thanks
Hi venkata,
Have you caught where it craches?
The patch is for enabling USB2.0 + USB3.0. Not sure but your device looks to be USB2.0. You may try to remove the configuration for USB3.0.
How to apply the patch?
Hi mganeff,
Please refer to https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-1
You should learn how to build kernel and device tree.
Hi DaneLLL,
I’m currently in a similar position as Venkata was, where the USB patch is applied and I can see a device, but I’m crashing.
Is there an updated patch for 28.2, or should it be the same as 28.1?
Also, would you be able to recommend a basic set of patch steps or provide the already patched device tree source?
I ask because I receive a few warnings when applying the patch, possibly due to it being for an earlier version (28.1)?
Thanks!
You will probably want to start a new thread. Add any information you can on your device, your current L4T version (“head -n 1 /etc/nv_tegra_release”), the output of “lsusb”, “lsusb -t”, and just for the one specific device “sudo lsusb -vvv” (the “-d ID” can be used to limit to just one ID…the regular lsusb shows ID in the format of “1234:4321”…if this happened to be your device ID you could run “sudo lsusb -d 1234:4321 -vvv”).
There’s a lot of difference between pre-R28.1 and R28.1+. There’s also some significant improvements on releases newer than R28.1. Any patch for a kernel earlier than R28.1 is pretty much guaranteed to be invalid on R28.1 (you’d be applying a 3.x kernel series patch to the entirely newer 4.x generation of kernel).