USB-To-USB Cable Bridge not working

I am trying to get a usb network cable to work with the tx2 development board.

I have an ubuntu 16.04 vm that is able to use this cable with no problems, but the tx2 does not seem to have the proper drivers installed.

This is the cable I have - Plugable USB 3.0 Windows SuperSpeed Transfer Cable – Plugable Technologies

Here is the output of usb-devices in my vm.

T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=067b ProdID=27a1 Rev=01.00
S:  Manufacturer=Prolific Technology Inc.
S:  Product=USB-To-USB Cable Bridge
S:  SerialNumber=PROLIFICMP000000001
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=96mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=plusb

Here is it on the tx2

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 61 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=067b ProdID=27a1 Rev=01.00
S:  Manufacturer=Prolific Technology Inc.
S:  Product=USB-To-USB Cable Bridge
S:  SerialNumber=PROLIFICMP000000001
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=96mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

Here is the output from sudo lsusb -v from my vm

Bus 004 Device 019: ID 067b:27a1 Prolific Technology, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x067b Prolific Technology, Inc.
  idProduct          0x27a1 
  bcdDevice            1.00
  iManufacturer           1 Prolific Technology Inc.
  iProduct                2 USB-To-USB Cable Bridge
  iSerial                 3 PROLIFICMP000000001
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           44
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower               24mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x08  EP 8 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x89  EP 9 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        2047 micro seconds
Device Status:     0x000c
  (Bus Powered)
  U1 Enabled
  U2 Enabled

Here it is from the tx2

Bus 002 Device 064: ID 067b:27a1 Prolific Technology, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x067b Prolific Technology, Inc.
  idProduct          0x27a1 
  bcdDevice            1.00
  iManufacturer           1 (error)
  iProduct                2 (error)
  iSerial                 3 (error)
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           44
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower               24mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x08  EP 8 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x89  EP 9 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
Device Status:     0x0401
  Self Powered

Seems that there is some error on the tx2 side as iManufacturer, iProduct, iSerial all report errors.

In my vm I noticed the kernel module that is used as the driver is plusb. The default tx2 image does not have the plusb kernel module. I added the following lines to tegra18_defconfig to compile this module and its dependencies.

CONFIG_USB_NET_PLUSB=m
CONFIG_USB_USBNET=m
CONFIG_MII=m

After recompiling the kernel with these options I had no change in the behavior of the device.

Can someone please help me get this usb device to work? Maybe I need to do some other configuration with the kernel? Please let me know if there is anything else I need to do to diagnose the problem.

Keep in mind that USB is nothing more than a hot plug data pipe…it sees what connects, it announces the description to a hot plug layer, and drivers see that announcement. If a driver can handle the device, then that driver takes ownership. Without that driver USB is basically just a blank wire with no understanding beyond relaying bits.

I looked at the manufacturer’s URL and it only claims compatibility with Windows. Some USB devices have standard drivers because they are a standard class interface, but this device seems entirely custom. You are correct that the driver appears to be missing, but without the manufacturer (or someone) providing a Linux driver it won’t work with anything other than Windows.

Someone may have already produced a Linux driver for this. I only viewed that URL you posted and it seems the manufacturer does not provide any other support. It isn’t unusual for a driver to exist somewhere in the wild, but this would take some research.

Hi linuxdev,

I understand the manufacture does not provide a linux driver. However, the default desktop version of ubuntu has a builtin driver that works with this device, “plusb”. It would seem to me since there is a driver that works on the desktop version that I should be able to get the same to work on the tx2. I tried recompiling the kernel with the configuration to include the PLUSB and USBNET drivers, but that did not fix the problem. It seems like there is some error regarding the device when it is plugged in as “lsusb -v” shows some errors in the fields I mentioned above.

On the kernel you built beware that there are changes over time in how the kernel is accessed. In newer releases the file in “/boot” may not be the actual used kernel and what you think you installed might not actually be running if you modified the actual kernel and not just modules.

First, editing tegra18_defconfig directly will often be a disaster. There are dependencies that the menu based editors understand. Was this directly edited as a file, or did you use an editor such as “make menuconfig”?

Did you correctly set the CONFIG_LOCALVERSION?

If you take the file “/proc/config.gz”, gunzip it, and then rename it as “.config”, the results will probably be better than using tegra18_defconfig (you’d still update CONFIG_LOCALVERSION). This is not a real file, it is content in RAM produced by the kernel giving its exact current running configuration (other than CONFIG_LOCALVERSION…but tegra18_defconfig may have multiple differences from your default running system).

Also, if there is a custom device driver addition, then there is also likely other content which works with the driver, e.g., a user space library or program. Have you added all support the desktop adds? Did the desktop add configuration in “/etc” or other files beyond the kernel module?

Hi linuxdev,

I am using jetpack 3.3

I was editing tegra18_defconfig directly which seems to have been a problem.

I tried to use the make menuconfig, but ran into some errors when compiling the kernel.

I ran “make menuconfig”

Then I loaded tegra18_defconfig

I then edited it and enabled Device Drivers / Network device support / USB Network Adapters / Multi-purpose USB Networking Framework / Prolific PL-2301/2302/25A1 based calbes

Then I saved the new configuration to mytegra18_defconfig

then I tried to make the new kernel.

make ARCH=$ARCH O=$KO mytegra18_defconfig
make ARCH=$ARCH O=$KO

ARCH=arm64, KO=output directory

There are some errors shown below that made the compilation fail.

CC      drivers/virtio/virtio.o
  LD [M]  drivers/usb/gadget/function/usb_f_ncm.o
  LOGO    drivers/video/logo/logo_spe_clut224.c
/home/sp/sandbox/jetpack/tx2/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4/drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu/gp10b/platform_gp10b_tegra.c:45:32: error: ‘CONFIG_GK20A_FREQ_SELECT_STEP’ undeclared here (not in a function)
 #define GP10B_FREQ_SELECT_STEP CONFIG_GK20A_FREQ_SELECT_STEP
                                ^
/home/sp/sandbox/jetpack/tx2/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4/drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu/gp10b/platform_gp10b_tegra.c:49:46: note: in expansion of macro ‘GP10B_FREQ_SELECT_STEP’
 gp10b_freq_table[GP10B_MAX_SUPPORTED_FREQS / GP10B_FREQ_SELECT_STEP];
                                              ^
/home/sp/sandbox/jetpack/tx2/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4/drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu/gp10b/platform_gp10b_tegra.c: In function ‘gp10b_clk_get_freqs’:
/home/sp/sandbox/jetpack/tx2/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4/drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu/gp10b/platform_gp10b_tegra.c:369:42: error: ‘CONFIG_GK20A_FREQ_SELECT_MIN’ undeclared (first use in this function)
  unsigned long prev_rate = 0, new_rate = CONFIG_GK20A_FREQ_SELECT_MIN;
                                          ^
/home/sp/sandbox/jetpack/tx2/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4/drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu/gp10b/platform_gp10b_tegra.c:369:42: note: each undeclared identifier is reported only once for each function it appears in
  CC      drivers/video/fbdev/core/fbmem.o
  LOGO    drivers/video/logo/logo_mac_clut224.c
/home/sp/sandbox/jetpack/tx2/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4/drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu/gp10b/platform_gp10b_tegra.c: At top level:
/home/sp/sandbox/jetpack/tx2/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4/drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu/gp10b/platform_gp10b_tegra.c:49:1: error: ‘gp10b_freq_table’ defined but not used [-Werror=unused-variable]
 gp10b_freq_table[GP10B_MAX_SUPPORTED_FREQS / GP10B_FREQ_SELECT_STEP];
 ^
cc1: all warnings being treated as errors
  LD      drivers/tty/vt/built-in.o
/home/sp/sandbox/jetpack/tx2/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4/scripts/Makefile.build:261: recipe for target 'drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu/gp10b/platform_gp10b_tegra.o' failed
make[4]: *** [drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu/gp10b/platform_gp10b_tegra.o] Error 1
/home/sp/sandbox/jetpack/tx2/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4/scripts/Makefile.build:406: recipe for target 'drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu' failed
make[3]: *** [drivers/gpu/../../../nvgpu/drivers/gpu/nvgpu] Error 2
/home/sp/sandbox/jetpack/tx2/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4/scripts/Makefile.build:406: recipe for target 'drivers/gpu' failed
make[2]: *** [drivers/gpu] Error 2
make[2]: *** Waiting for unfinished jobs....
  CC      drivers/video/fbdev/core/fbmon.o

The errors don’t seem to be related to the option I enabled. Can you help me make sense of them? The mytegra18_defconfig that I generated from make menuconfig is much bigger than the original tegra18_defconfig. I have included the mytegra18_defconfig if that helps. Am I doing something wrong? If I follow the same procedure, but don’t enable that extra feature I am able to compile without any problems.
mytegra18_defconfig.txt (143 KB)

Keep in mind that any change to the config is literally changing what code is compiled. The same code with two different configurations can be considered completely different programs (though with a lot in common).

Can you put the original kernel back in? Then save a copy of “/proc/config.gz”. Once CONFIG_LOCALVERSION is set (based on the suffix of “uname -r”) you have an absolute guarantee that this configuration is an exact match to the running kernel. Be sure to save a copy somewhere safe.

Once you have that see if you can compile without modification. Then use “make nconfig” (or other config editor) to add your changes. If the previous compile worked, but this compile fails, post the error here along with what items you added from the config editor.

FYI, I use “make nconfig” because it has an ability to search for symbols or to make visible otherwise invisible symbols (useful when finding out why an option doesn’t show up).

Sorry we had a big snow storm and the office was closed most of the week.

Can you tell me if I am going about this the correct way.

I am running make nconfig

I load arch/arm64/configs/tegra18_defconfig

I then save this as arch/arm64/configs/mytegra18_defconfig

if I then run

make ARCH=$ARCH O=$KO mytegra18_defconfig
make ARCH=$ARCH O=$KO

it works fine.

If I change anything in the kernel parameters including CONFIG_LOCALVERSION and then save to mytegra18_defconfig the compilation fails. I am compiling on a ubuntu 16.04 virtual machine as per the jetpack instructions. the errors I get after adding CONFIG_LOCALVERSION are shown above in my previous post.
If i look at the two mytegra18_defconfigs changing CONFIG_LOCALVERSION changed quite a few things in the kernel configuration that I don’t understand.

mytegra18_defconfig (added localversion).txt (140 KB)

mytegra18_defconfig (unchange from tegra18_defconfig).txt (143 KB)

Technically this is correct, but if you are keeping the original kernel and building modules, then this is suspect because you don’t know it is the same as that running kernel:

I load arch/arm64/configs/tegra18_defconfig

…this is where I suggest replacing with manual copy of “/proc/config.gz” (after gunzip) to the top level directory of the kernel build. This would replace the defconfig with a known almost-exact copy. If CONFIG_LOCALVERSION is set, then it is an exact copy of the running system. If you were to copy this version to “mytegra18_defconfig”, then you would have the perfect starting config.

For the CONFIG_LOCALVERSION, if the base version is “4.4.38”, then CONFIG_LOCALVERSION of “tc” means “uname -r” would become “4.4.38tc”. I typically put a hyphen in, which isn’t actually important, but it can be nice for readability (you might consider “-tc” instead of “tc”). These modules would be designed to work with a kernel looking for modules in “/lib/modules/4.4.38tc/”. The original kernel (“uname -r” of “4.4.38-tegra”) would be looking in “/lib/modules/4.4.38-tegra/”. Unless you add both kernel and modules, then this will probably have issues (there are workarounds, but it is easier to just do it right).

Where did you get your kernel source? Some published sources lack code specific to Jetsons (some “out of tree” code). Did you use “source_sync.sh” or one of the NVIDIA download sources which has “sources/kernel/kernel-4.4/” and also “sources/hardware/nvidia/”? There are certain features in the kernel source specific to this platform, which when enabled, require including files in a relative path within that hardware directory.

I can’t say much about the errors based on seeing just a config file. The concept of changing config with “make nconfig” is correct, and so dependencies would have been correctly preserved (errors would not be due to missing dependencies in configuration). So there remains two questions: Did you use the source_sync.sh script (or something compatible) for getting the kernel source, and can you present the logs of the points of failure?

As an aid, if you were to compile on a system with 8 cores, then you might use “make -j8”. One thread of compile might fail and the build might not stop till much later. If this happens, and you build again with just “make -j1”, then only a single build thread will be used and the output for logging would be easier to read…the point of failure would stop the compile right then without seeing the print from other build messages. About one or two paragraphs of build output at a failure would be very useful to see. Seeing the actual errors with the context of what occurred right before this is important.

Btw, if you want to log an entire build (instead of just copy and paste of some part), then just append this at the end of your build command line (unless it is complicated I’d just mouse copy after a “make -j1”):

2>&1 | tee build_log.txt

Hi linuxdev,

I was finally able to get the kernel to compile with the plusb module by taking the /proc/config.gz off the running tx2. I still don’t understand why I couldn’t get it to work with tegra18_defconfig from the kernel sources obtained with the source_sync.sh utility. This is in the instructions in the nvl5t_docs under Kernel Customization. Maybe I am missing something, but it seems like the instructions need to be updated or clarified.

In any case the plusb module is older than the one running on desktop ubuntu. It does not support the exact model of my cable. So i guess this will not work without patching the kernel.

Thank you for all your help.

In the early days the defconfig was the same as the config from the shipping unit. I’m not sure what the changes are now, but I have noticed there is no longer an “exact” match (perhaps for practical purposes it is the same…don’t know). Keep in mind that there are several platforms (including carrier board combinations) supported by that one kernel release…that defconfig is probably the default for one of them, but perhaps not for the one you are using.

I am only guessing, but I suspect that documentation was an edit of some previous release of documentation. It is very easy to miss details like that of the difference between a defconfig file and the version which ships on any module/carrier combination.

If you ask the authors of the plusb cable about differences in version, then you might be able to get it to work by adding the manufacturer and device ID to the table of IDs in the source code of the driver. Assuming you have that source code it is actually much easier to do than it sounds (every USB device has a manufacturer ID and a product ID…there is literally a table of combinations of this the driver will have and it is easy to append one more pair). If a newer device comes out then older drivers simply would not have known about that ID even if the device uses the same drivers.