USB ethernet gadget not connecting on Jetson TX2

Autonomous Machines Jetson & Embedded Systems Jetson TX2
,
1

I have a sensor that uses an OTG connection to create a USB ethernet connection.
In lsusb it shows up as: Netchip Technology, Inc. Linux-USB Ethernet/RNDIS Gadget

I am unable to get the USB ethernet connection to form on the Jetson TX2 so I cannot ping the device. The device does work on the Raspberry Pi 3, a standard Ubuntu machine, and a Ubuntu VM.

I tried installing the following drivers to resolve the problem:
CONFIG_USB_ETH
CONFIG_USB_ETH_RNDIS
and many other gadget drivers, however I do not think this is the issue as these drivers must be on the target, not the host machine.

The device’s IP is 192.168.7.2, which is a statically set IP from the manufacturer. I have tried setting the port to 192.168.7.10 and 192.168.7.11 and 192.168.7.1 manually as the manufacturer suggested, but am still unable to reach the device.

Has anyone else worked with a similar device or have suggestions on what I can do to ping the device from the Jetson?

Thanks,
sathyas

3

Hi,

Actually I am confused by your request and the solution you’ve tried there. By default, the OTG port on the jetson already has usb eth interface supported with rel-32.x release. Which means you don’t need to compile anything from kernel, just connect the otg port to your host and it shall give you an interface between host and device.

I would suggest you can try this basic usecase first.

4

On the TX2 dev kit board there is only one USB 3.0 port, so it must be the OTG port correct? I have already tried this but the connection never forms. The Jetson just keeps searching for a signal.

5

Devkit has a OTG port on it. That is the port using for flash, and it is also for usb eth interface. Because such feature is based on usb device mode, it has to be on OTG port. Type A port by its nature cannot work as device mode.

Please remember that rel-28 based release does not support this. So make sure you are on rel-32.x release…

6

I am not using the Jetson as the device though, the sensor is used as the device. The sensor has a micro usb B port and I have been testing it on the other machines (laptop, Rpi3, VM) using USB A. Also my release is 32.2.1.

7

Ok, so the direction is reversed. Then we have no direct solution to support this.

Maybe other users can share their experience.

8

Maybe I can get some more details to give a better idea of what is failing. So this is a device, and it uses USB3, and the OTG port is on the device, not the Jetson? This should work using the USB3 port of the Jetson (at least with newer releases, not sure how much USB3 changed from R28.x to R32.x).

If you are logged into the Jetson, but the device is not yet plugged in, monitor “dmesg --follow”. Then, when you plug in the device, new log lines should show up. Can you post the new dmesg log lines? Also, can you post (after the device is plugged in to the Jetson) the output of “lsusb” and “lsusb -t”?

9

The device is uses USB 2 and correct the OTG port is on the device, not the Jetson. I am also surprised how the TX2 is unable to connect to the device, it just keeps searching for the signal.

dmesg --follow:

[   55.721691] usb 1-1.2: Product: RNDIS/Ethernet Gadget
[   55.721694] usb 1-1.2: Manufacturer: Linux 4.14.98+g8fb52d24865c with 2184000.usb
[   55.730848] cdc_subset 1-1.2:1.0 usb0: register 'cdc_subset' at usb-3530000.xhci-1.2, Linux Device, 62:80:b8:7c:77:66
[   55.816201] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready

after some time I see the following error in dmesg --follow:

[  101.170127] cdc_subset 1-1.2:1.0 usb0: kevent 12 may have been dropped
[  101.176696] cdc_subset 1-1.2:1.0 usb0: kevent 12 may have been dropped
[  101.183412] cdc_subset 1-1.2:1.0 usb0: kevent 12 may have been dropped

lsusb and lsusb -t: (It is the netchip device w/ cdc_subset driver)

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 04f2:0939 Chicony Electronics Co., Ltd
Bus 001 Device 005: ID 0525:a4a2 Netchip Technology, Inc. Linux-USB Ethernet/RNDIS Gadget
Bus 001 Device 003: ID 413c:2107 Dell Computer Corp.
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/3p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 2: Dev 5, If 0, Class=Communications, Driver=cdc_subset, 480M
        |__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
10

On my raspberry Pi 3, ubuntu machine, and VM the cdc_subset driver is set to =m rather than =y (it is =y on the Jetson). I don’t think this should be an issue but potentially it has to be set as a loadable module rather than directly built into the kernel. I see the modules cdc_subset and cdc_eem in lsmod when running the device on the other machines.

11

Oh I just realized that on the laptop and the raspberry pi 3, the driver used is cdc_eem rather than cdc_subset, which I have not tried enabling on the Jetson. I will try setting cdc_eem as a loadable module and fingers crossed it works.

12

I was able to get it to work by enabling the cdc_eem driver!!! Thanks!

13

Just answering in order as I read the above…

Ok, so in theory the device should show up as a USB2 device if the cable at the OTG port of the device is a type-B cable. FYI, if you don’t know about the quality of the cable and are using some random “charger” cable, then there is a strong chance the problem is signal quality (very few “OTG”/“charger” cables sold at the local store have sufficient quality for consistent data exchange, especially at USB2+ speeds). If you try with the micro-B USB cable which comes with a Jetson dev kit, does that work (assuming you have one)?

If you monitor “dmesg --follow” on the Jetson, then what do you see at the moment you plug in the cable?

The error message suggests it is a CDC ether driver. Just out of curiosity, what do you see from “lsmod” when the cable is inserted? FYI, there are multiple reasons why an event might be dropped, so it is hard to say what causes this.

For the lsusb output, is the ID “04f2:0939” the one which goes with your device? If it is, then what do you see from:
sudo lsusb -d 04f2:0939 -vvv
(you could log this with “sudo lsusb -d 04f2:0939 -vvv 2>&1 | tee log_lsusb.txt”)

Do note that if the ID 04f2:0939 is the correct device, that in “lsusb -t” it shows this as having backed off speed all the way down to “1.5Mb/s” (USB1.0), which would indicate “probably” a signal quality issue (a USB2 device should show as “480M”).

14

Hi, I was able to solve the issue. When viewing dmesg --follow on my laptop and on the Raspberry Pi, I noticed that it was using the cdc_eem driver rather than cdc_subset. Issue is resolved!

16

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.