TK1 Ethernet over USB

Robotics & Edge Computing Jetson & Embedded Systems Jetson TK1
1

I’m currently trying to get a Emlid Reach RTK GNSS module (a Intel Edison device) connected to the TK1 via Ethernet over USB. When I ssh into the Edison and run ifconfig, I can see the usb0 network device at 192.168.2.15 which is set as the default address. Emlid claims once the Reach has booted, a usb network device should show up [url]https://docs.emlid.com/reach/software-development/[/url]. Is there anything special I have to do for the TK1 USB configuration to get this working? There seems to be little support on this topic.

For my setup, I have a USB hub connected to the TK1 that has external power. The Reach draws around 1 Amp through USB and it seems the board can’t supply that. I have other devices (imu, Zed, DC motor controller) on this hub but are disconnected for troubleshooting. I’ve enabled USB 3.0 as well as disabled USB Autosuspend. This didn’t work but I can see the Edison on the lsusb return. A USB to Ethernet adapter doesn’t work either (Emlid devs claim that this should work as well).

Any thoughts?

2

USB itself is just a pipe. If USB sees the device, then other drivers must take over (the hotplug layer would ask drivers to take over…a driver which knows about the device would respond). To see if USB sees the device, find out if it appears under “lsusb”. You may want to create a list of what shows up under lsusb, and then plug the device in, followed by comparing what lsusb now shows. You may also want to look at “dmesg | tail -n 30” to see what is appended to dmesg logs right after plugging in the device.

Note that 1A requires a USB3 port…I believe this exceeds USB2 capacity. It is suggested to use a powered HUB if you have issues with power delivery. Note that you may need to put the USB port in USB3 mode (the full-sized USB connector could be in USB2 mode). If you look at USB on the Jetson via “lsusb -t” you get a tree view…at the right side of each device is a number showing speed. 480M is the USB2 speed, 5000M is USB3 speed (12M and 1.5M are typically keyboards and mice in USB1.1 mode). If the parent device is capable of USB3, then the device plugged in can also achieve USB3. See if USB3 shows up via 5000M.

FYI, some devices do not expect to provide USB2 compatibility, and as such, a port not in USB3 mode may not be functional if the device does not provide USB2 compatibility. Your device may draw enough power that no USB2 mode was considered as an option.

So far as this particular device goes, if it is designed as a generic USB class, then no special drivers will be needed…known non-custom USB devices already have drivers to take over when hotplug announces the device. If the device is custom, then a custom driver is required. Note that if you are looking at the output of “lsusb”, then one of the columns of output is an ID. You can name this ID to get lsusb output specific to this device. These example ID numbers are not for your device, but to see a very verbose listing for one specific device by ID would look like this (edit the ID to match your lsusb):

lsusb -d 0955:7140 -vvv

You may want to attach the verbose listing here to see about whether this is a custom device or a known class (you would want to mark it as a code block via the “</>” icon). In the case of USB3 running on USB2 it won’t matter since lack of USB3 would cause only a partial response from a device which makes USB3 mandatory. If you need the port to be USB3 mode and it is not already there, just ask. One limitation will be that the boot loader would need reprogramming to get USB3 mode…the boot loader is actually separate software from Linux, so if you need USB3 while in the boot loader you may be out of luck.

3

Thanks for the response! Here is the verbose listing I see:

ubuntu@tegra-ubuntu:~$ lsusb -d 8087:0a9e -vvv

Bus 001 Device 007: ID 8087:0a9e Intel Corp. 
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x8087 Intel Corp.
  idProduct          0x0a9e 
  bcdDevice            3.10
  iManufacturer           2 
  iProduct                3 
  iSerial                 4 
  bNumConfigurations      1
OTG Descriptor:
  bLength                 3
  bDescriptorType         9
  bmAttributes         0x03
    SRP (Session Request Protocol)
    HNP (Host Negotiation Protocol)
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          167
    bNumInterfaces          5
    bConfigurationValue     1
    iConfiguration          5 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              500mA
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       6 Ethernet Networking
      bFunctionProtocol       0 
      iFunction               9 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol    255 Vendor Specific (MSFT RNDIS?)
      iInterface              7 
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x00
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               9
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              8 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         2
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       1 AT-commands (v.25ter)
      iFunction              12 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface             10 
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          3
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        2
        bSlaveInterface         3 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x000a  1x 10 bytes
        bInterval               9
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface             11 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1

I rebooted the device and ran

dmesg | tail -n 30

The result:

[ 3212.514876] usb 1-3.1: USB disconnect, device number 7
[ 3212.527896] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 3212.528650] sd 2:0:0:0: [sda]  
[ 3212.528694] Result: hostbyte=0x01 driverbyte=0x00
[ 3240.593760] usb 1-3.1: new high-speed USB device number 9 using tegra-xhci
[ 3240.607023] usb 1-3.1: New USB device found, idVendor=8087, idProduct=0a99
[ 3240.607078] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3240.607117] usb 1-3.1: Product: USB download gadget
[ 3240.607152] usb 1-3.1: Manufacturer: Intel
[ 3243.491554] usb 1-3.1: USB disconnect, device number 9
[ 3250.830265] usb 1-3.1: new high-speed USB device number 10 using tegra-xhci
[ 3250.842583] usb 1-3.1: New USB device found, idVendor=8087, idProduct=0a9e
[ 3250.842589] usb 1-3.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4
[ 3250.842593] usb 1-3.1: Product: Edison
[ 3250.842596] usb 1-3.1: Manufacturer: Intel
[ 3250.842600] usb 1-3.1: SerialNumber: e938ef736bb5ad2ee091322a6342f85f
[ 3250.844552] cdc_acm 1-3.1:1.2: This device cannot do calls on its own. It is not a modem.
[ 3250.853260] cdc_acm 1-3.1:1.2: ttyACM0: USB ACM device
[ 3250.854029] usb-storage 1-3.1:1.4: USB Mass Storage device detected
[ 3250.854158] scsi3 : usb-storage 1-3.1:1.4
[ 3251.857807] scsi 3:0:0:0: Direct-Access     Linux    File-CD Gadget   0310 PQ: 0 ANSI: 2
[ 3251.862140] sd 3:0:0:0: Attached scsi generic sg0 type 0
[ 3251.863034] sd 3:0:0:0: [sda] 1572864 512-byte logical blocks: (805 MB/768 MiB)
[ 3251.864057] sd 3:0:0:0: [sda] Write Protect is off
[ 3251.864112] sd 3:0:0:0: [sda] Mode Sense: 0f 00 00 00
[ 3251.864965] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 3251.877243]  sda: sda1
[ 3251.878721] sd 3:0:0:0: [sda] Attached SCSI disk
[ 3252.079609] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 3252.221284] systemd-hostnamed[2364]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!

Is “nss-myhostname” required here? Apologies, I’m relatively new to linux.

4

Before looking at the rest of this, was the port running in USB3 mode (5000M with “lsusb -t”)? I’m interested in first looking at the tree view to see a generic layout of what is connected (and USB devices might show as more than one thing…a single wire can support multiple devices or interfaces).

Since I’m not familiar with the device (though I’m skimming through the web pages on the topic…this is a rather cool piece of technology), what is your intended configuration for this device? From what I can tell this device has a Linux operating system hidden in it under the covers, and has an ability to configure its USB port to act differently depending on configuration. In your case is it correct to assume the USB is intended to appear as a network adapter (with the Emlid Reach at address 192.168.42.1)?

Assuming this is to look like a network device, what is your Jetson’s “ifconfig” output? It would be important that your Jetson’s network be configured to see the same subnet as the Emlid Reach. I’m still searching documents to see what kind of driver requirements are noted for computers using the device on USB.

FYI, I doubt the nss would have any effect on your issue. I do see an issue about a VFAT partition being incorrectly mounted and thus possibly corrupt. Is this referring to the Emlid Reach being visible as a disk, or do you have other mass storage connected?

5

It is a very neat device. So the address you mentioned (192.168.42.1) is the address of the WiFi network the on-board Intel Edison hosts. I bridged this network with a router on my rover that was also connected to the TK1. With a second Reach module acting as a base station on the same WiFi network, I was able to get GPS coordinates to the rover with about 3 cm accuracy. However, my current application demands an operating range that extends further than 2.4 GHz WiFi. I’m now using high power IP radios that are similar to a router minus the wireless access point. Thus, I need a hardwired connection for the Reach to get on the network.

The usb0 device on the Reach is configured as a network device. Here is the Reach ifconfig:

Reach_Rover:~$ ifconfig
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:725 errors:0 dropped:0 overruns:0 frame:0
          TX packets:725 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:64228 (62.7 KiB)  TX bytes:64228 (62.7 KiB)

usb0      Link encap:Ethernet  HWaddr 02:00:86:42:f8:5f  
          inet addr:192.168.2.15  Bcast:192.168.2.255  Mask:255.255.255.0
          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)

wlan0     Link encap:Ethernet  HWaddr fc:c2:de:3d:98:d2  
          inet addr:192.168.42.1  Bcast:192.168.42.255  Mask:255.255.255.0
          inet6 addr: fe80::fec2:deff:fe3d:98d2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:395 errors:0 dropped:0 overruns:0 frame:0
          TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:59816 (58.4 KiB)  TX bytes:13457 (13.1 KiB)

Also, here is the usb tree view on the TK1 side:

ubuntu@tegra-ubuntu:~$ lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/2p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M
    |__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 23, If 0, Class=Communications, Driver=, 480M
        |__ Port 1: Dev 23, If 1, Class=CDC Data, Driver=, 480M
        |__ Port 1: Dev 23, If 2, Class=Communications, Driver=cdc_acm, 480M
        |__ Port 1: Dev 23, If 3, Class=CDC Data, Driver=cdc_acm, 480M
        |__ Port 1: Dev 23, If 4, Class=Mass Storage, Driver=usb-storage, 480M

So the port isn’t running in USB3 mode. However, it seems there’re drivers missing? Or am I reading this wrong?

6

Sorry, missed a couple of your questions. Here is the Jetson’s ifconfig. When working correctly, a usb network device should appear here.

ubuntu@tegra-ubuntu:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:04:4b:49:17:9b  
          inet addr:192.168.2.120  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::204:4bff:fe49:179b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1510 errors:0 dropped:0 overruns:0 frame:0
          TX packets:260 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:141499 (141.4 KB)  TX bytes:32068 (32.0 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:80 errors:0 dropped:0 overruns:0 frame:0
          TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:6368 (6.3 KB)  TX bytes:6368 (6.3 KB)

Yes, the Emlid Reach is visible as a disk also.

I’ve tried editing the /etc/network/interfaces file.

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto eth0
iface eth0 inet dhcp
iface usb0 inet static
  address 192.168.2.2
  netmask 255.255.255.0
dns-nameservers 8.8.8.8 8.8.4.4

This didn’t work.

ubuntu@tegra-ubuntu:~$ sudo ifup usb0
Cannot find device "usb0"
Failed to bring up usb0.
7

There are times when not every port needs to list a driver, e.g., there could be more than one interface to hardware, e.g., a port might show up for a HUB which has nothing on it…no driver would be associated.

To verify, the usb0 under Reach_Rover is what you see from the Linux system within the embedded Reach, and not from the Jetson? If so, then this would validate that the Reach_Rover is configured correctly for USB to present itself as a network device to the Jetson.

The ifconfig which is from the Jetson indicates wired networking is set up and enabled, but no WiFi (which is probably irrelevant for this and what you intended). I should have had you use “ifconfig -a” to be sure any interface would show, even if down. Does ifconfig show the same thing with and without the “-a” argument? I suspect the “-a” won’t show anything like usb0, but it is worth checking.

Note that without ifconfig seeing a usb0 interface you won’t be able to do anything related to setting this up. Lack of usb0, yet showing existence under lsusb, tends to imply you need a custom driver to handle this device (custom does not necessarily imply it has to be distributed in binary format by the manufacturer…it just means the driver is not a generic class handled without adding drivers). So the next thing is to know which driver the Jetson’s kernel needs to have in order for USB to hotplug the driver upon seeing the device. This seems to be your missing link.

It may be that whoever sells this device normally uses it on another flavor of Linux which typically has the driver in place, and thus the documents may have left out information on what driver to install. What I’m wondering (the docs don’t seem to show this just skimming through) is what type of computer the USB would normally plug into? For example, Windows 7, Mac, or desktop Linux PCs. Some of those systems quite possibly include drivers by default which the Jetson would need to have added manually. Can you find out what drivers and host operating system might be required? Knowing what chipset the USB version presents itself as would be a close second to knowing what driver is expected…chipsets tend to all use the same driver (or minor variant of that driver). Basically there should be a “requirements” doc somewhere with the device regarding the USB side (the mass storage part is generic and can be ignored, it’s a question of why kind of ethernet device is presented over USB since it is not a generic class).

8

Yes, that is what I see within the embedded Reach.

ubuntu@tegra-ubuntu:~$ ifconfig -a
dummy0    Link encap:Ethernet  HWaddr 36:0e:4b:c7:eb:31  
          BROADCAST NOARP  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:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:04:4b:49:17:9b  
          inet addr:192.168.2.120  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::204:4bff:fe49:179b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:691 errors:0 dropped:0 overruns:0 frame:0
          TX packets:156 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:60361 (60.3 KB)  TX bytes:20010 (20.0 KB)

ip6tnl0   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          NOARP  MTU:1452  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:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:80 errors:0 dropped:0 overruns:0 frame:0
          TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:6368 (6.3 KB)  TX bytes:6368 (6.3 KB)

rmnetctl  Link encap:IPIP Tunnel  HWaddr   
          NOARP  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:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  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:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

This list doesn’t change when I disconnect the Reach from the USB hub. Apparently, this feature should be working with Ubuntu out of the box. I tested Ethernet over USB with the Reach on my Windows PC and everything seems fine. I’ll try to dig around for a linux driver and report back. Thanks so much for your help thus far!

9

Incidentally, if you use a desktop Linux PC and the driver loads, it is a strong possibility that you can see the driver name via “lsmod”. You may want to boot your Linux desktop PC without the hardware, run “lsmod” and save the results to a file…then plug in the USB device and run “lsmod” again to see if there are new modules loaded (this will of course fail if the feature is integrated into the kernel and not a module, but odds are extremely high that any non-generic feature is built as a module).

10

Okay, I took your advice and performed the “lsmod” test on a Ubuntu PC. The Ethernet over USB feature was essentially “plug and play” minus some minor setup in the /etc/network/interfaces file.

Output before the Reach connected:

Module                  Size  Used by
michael_mic            12612  4 
arc4                   12608  2 
snd_hda_codec_hdmi     46254  1 
bnep                   19624  2 
rfcomm                 69160  8 
btusb                  32412  0 
uvcvideo               80885  0 
bluetooth             391196  22 bnep,btusb,rfcomm
videobuf2_vmalloc      13216  1 uvcvideo
videobuf2_memops       13362  1 videobuf2_vmalloc
videobuf2_core         40664  1 uvcvideo
xpad                   18218  0 
ff_memless             13573  1 xpad
videodev              134688  2 uvcvideo,videobuf2_core
snd_hda_codec_idt      54645  1 
dell_wmi               12761  0 
sparse_keymap          13948  1 dell_wmi
dell_laptop            18168  0 
dcdbas                 14928  1 dell_laptop
snd_hda_intel          52355  5 
lib80211_crypt_tkip    17619  0 
snd_hda_codec         192906  3 snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_intel
snd_hwdep              13602  1 snd_hda_codec
intel_rapl             18773  0 
x86_pkg_temp_thermal    14205  0 
intel_powerclamp       14705  0 
coretemp               13435  0 
kvm_intel             143060  0 
snd_pcm               102099  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
kvm                   451511  1 kvm_intel
snd_page_alloc         18710  2 snd_pcm,snd_hda_intel
crct10dif_pclmul       14289  0 
snd_seq_midi           13324  0 
snd_seq_midi_event     14899  1 snd_seq_midi
crc32_pclmul           13113  0 
ghash_clmulni_intel    13216  0 
snd_rawmidi            30144  1 snd_seq_midi
aesni_intel            55624  0 
snd_seq                61560  2 snd_seq_midi_event,snd_seq_midi
aes_x86_64             17131  1 aesni_intel
lrw                    13286  1 aesni_intel
gf128mul               14951  1 lrw
glue_helper            13990  1 aesni_intel
radeon               1522422  3 
ablk_helper            13597  1 aesni_intel
cryptd                 20359  3 ghash_clmulni_intel,aesni_intel,ablk_helper
snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer              29482  2 snd_pcm,snd_seq
joydev                 17381  0 
wl                   4207846  0 
serio_raw              13462  0 
ttm                    85115  1 radeon
lib80211               14381  2 wl,lib80211_crypt_tkip
drm_kms_helper         53081  1 radeon
cfg80211              484040  1 wl
snd                    69238  21 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_idt,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
drm                   303102  5 ttm,drm_kms_helper,radeon
lpc_ich                21080  0 
i2c_algo_bit           13413  1 radeon
soundcore              12680  1 snd
video                  19476  0 
wmi                    19177  1 dell_wmi
mei_me                 18627  0 
mei                    82276  1 mei_me
mac_hid                13205  0 
parport_pc             32701  0 
ppdev                  17671  0 
lp                     17759  0 
parport                42348  3 lp,ppdev,parport_pc
hid_generic            12548  0 
hid_logitech_dj        18581  0 
usbhid                 52570  0 
hid                   106148  5 hid_generic,usbhid,hid_logitech_dj
e1000e                254433  0 
firewire_ohci          40409  0 
ahci                   25819  2 
sdhci_pci              23172  0 
firewire_core          68769  1 firewire_ohci
psmouse               106678  0 
ptp                    18933  1 e1000e
libahci                32560  1 ahci
sdhci                  43015  1 sdhci_pci
crc_itu_t              12707  1 firewire_core
pps_core               19382  1 ptp

After the Reach connected and booted up:

Module                  Size  Used by
nls_iso8859_1          12713  1 
rndis_wlan             50281  0 
usb_storage            62209  1 
rndis_host             14503  1 rndis_wlan
cdc_ether              14351  1 rndis_host
cdc_acm                28803  0 
usbnet                 43913  3 rndis_host,rndis_wlan,cdc_ether
mii                    13934  1 usbnet
michael_mic            12612  4 
arc4                   12608  2 
snd_hda_codec_hdmi     46254  1 
bnep                   19624  2 
rfcomm                 69160  8 
btusb                  32412  0 
uvcvideo               80885  0 
bluetooth             391196  22 bnep,btusb,rfcomm
videobuf2_vmalloc      13216  1 uvcvideo
videobuf2_memops       13362  1 videobuf2_vmalloc
videobuf2_core         40664  1 uvcvideo
xpad                   18218  0 
ff_memless             13573  1 xpad
videodev              134688  2 uvcvideo,videobuf2_core
snd_hda_codec_idt      54645  1 
dell_wmi               12761  0 
sparse_keymap          13948  1 dell_wmi
dell_laptop            18168  0 
dcdbas                 14928  1 dell_laptop
snd_hda_intel          52355  5 
lib80211_crypt_tkip    17619  0 
snd_hda_codec         192906  3 snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_intel
snd_hwdep              13602  1 snd_hda_codec
intel_rapl             18773  0 
x86_pkg_temp_thermal    14205  0 
intel_powerclamp       14705  0 
coretemp               13435  0 
kvm_intel             143060  0 
snd_pcm               102099  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
kvm                   451511  1 kvm_intel
snd_page_alloc         18710  2 snd_pcm,snd_hda_intel
crct10dif_pclmul       14289  0 
snd_seq_midi           13324  0 
snd_seq_midi_event     14899  1 snd_seq_midi
crc32_pclmul           13113  0 
ghash_clmulni_intel    13216  0 
snd_rawmidi            30144  1 snd_seq_midi
aesni_intel            55624  0 
snd_seq                61560  2 snd_seq_midi_event,snd_seq_midi
aes_x86_64             17131  1 aesni_intel
lrw                    13286  1 aesni_intel
gf128mul               14951  1 lrw
glue_helper            13990  1 aesni_intel
radeon               1522422  3 
ablk_helper            13597  1 aesni_intel
cryptd                 20359  3 ghash_clmulni_intel,aesni_intel,ablk_helper
snd_seq_device         14497  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer              29482  2 snd_pcm,snd_seq
joydev                 17381  0 
wl                   4207846  0 
serio_raw              13462  0 
ttm                    85115  1 radeon
lib80211               14381  2 wl,lib80211_crypt_tkip
drm_kms_helper         53081  1 radeon
cfg80211              484040  2 wl,rndis_wlan
snd                    69238  21 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_idt,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
drm                   303102  5 ttm,drm_kms_helper,radeon
lpc_ich                21080  0 
i2c_algo_bit           13413  1 radeon
soundcore              12680  1 snd
video                  19476  0 
wmi                    19177  1 dell_wmi
mei_me                 18627  0 
mei                    82276  1 mei_me
mac_hid                13205  0 
parport_pc             32701  0 
ppdev                  17671  0 
lp                     17759  0 
parport                42348  3 lp,ppdev,parport_pc
hid_generic            12548  0 
hid_logitech_dj        18581  0 
usbhid                 52570  0 
hid                   106148  5 hid_generic,usbhid,hid_logitech_dj
e1000e                254433  0 
firewire_ohci          40409  0 
ahci                   25819  2 
sdhci_pci              23172  0 
firewire_core          68769  1 firewire_ohci
psmouse               106678  0 
ptp                    18933  1 e1000e
libahci                32560  1 ahci
sdhci                  43015  1 sdhci_pci
crc_itu_t              12707  1 firewire_core
pps_core               19382  1 ptp

Difference between the two:

diff lsmod_output1.txt lsmod_output2.txt
1a2,9
> nls_iso8859_1          12713  1 
> rndis_wlan             50281  0 
> usb_storage            62209  1 
> rndis_host             14503  1 rndis_wlan
> cdc_ether              14351  1 rndis_host
> cdc_acm                28803  0 
> usbnet                 43913  3 rndis_host,rndis_wlan,cdc_ether
> mii                    13934  1 usbnet
56c64
< cfg80211              484040  1 wl
---
> cfg80211              484040  2 wl,rndis_wlan

So, I’m assuming I need to install these modules on the TK1. I don’t really understand why these modules are on Linux PC’s and not the Jetson?

11

It is likely those modules do need to be installed on the Jetson.

A desktop PC has all kinds of expansion slots and you never know what a desktop user will end up with…it’s a convenience to have all those modules, but an embedded system can’t possibly use the same combination. You could be wasting 16GB of hard drive storing modules you don’t use on your desktop…that’s the entire size of the Jetson’s storage.

A second reason to not build lots of modules on a Jetson is that module loading limitations differ between architectures. For the mechanism to work you need the direct branch instruction. For x86_64 direct branching works over a very large address range (I have no idea how much, but it is a lot). On a 32-bit ARM system direct branch has a 32MB limit. The entire space of your initrd code and modules must remain less than 32MB or you will get mysterious errors from unreachable code when the branch is attempted…depending on options, typically initrd would occupy the first 24MB of physical memory below the kernel, and then modules would occupy the next 8MB below that in physical address. In that scheme more than 8MB of modules loaded at once would guarantee system failures (and some would probably be rather bizarre, not too different from corruption).

Incidentally, on the TX1 (aarch64/arm64/ARMv8-A) the 64-bit direct branch gets a bump up and allows 128MB. I’m not sure where or how the initrd and module space is divided on that, but division of space between modules and initrd would be a lot less restrictive there.

So…these systems may be as powerful as a desktop for some purposes, but don’t forget this is an embedded system and not a general purpose computer…the architecture and hardware limitations make it impractical to put drivers on it for everything just in case someone might use them (this would for example imply drivers for AMD video cards, thousand dollar 10G-base-T networking, and thousand dollar fiber network storage systems…I doubt many people use those on a Jetson).

12

I see, thanks for the explanation. So I’ll try to get those modules on the Jetson. I guess a USB to Ethernet adapter wouldn’t work in this case?

13

You need the driver, and it sounds like the drivers are available such that you just need kernel modules for those drivers. Some features are available via module, and thus nothing more needs to be added (you wouldn’t even need to reboot, you’d just run module commands…though reboot would do that for you). In other cases some kernel features must be integrated into the kernel and not used as a module…in that case you’d need to build the full kernel and module tree (this does not require flashing, but it is a more extensive copy).

When you do go to build kernel modules you would start by configuring the kernel with an exactly matching configuration to the current running kernel. With the exception of one detail you should be able to get this from the running system’s “/proc/config.gz” (just gunzip it and change the name to .config before starting your kernel configuration). CONFIG_LOCALVERSION must also match the running system, and this is not preserved in config.gz. You can edit the copied config file and replace the empty string:

CONFIG_LOCALVERSION=""

…to instead match the suffix of “uname -r”. So if for example “uname -r” responds “3.10.40-ga7da867”, then “” would become “-ga7da876”.

This can be built natively on the JTK1, you don’t need to cross compile. Kernel source is available here if running L4T R21.5:
https://developer.nvidia.com/linux-tegra-r215

More details are available if required.