Jetson TX2 - USB Hub problem

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

I am using Jetson TX2 with Orbitty Carrier board. It has one USB port and I am using it with a USB-HUB device. When I plugged a keyboard and mouse they work fine. However when I plugged a rs232 to USB converter, I observed that none of my devices are getting an adress.

What I mean is when I type “lsusb” to terminal, I saw the brand of my USB devices but when I type “lsusb /dev/tty*” I couldn’t see any change after I plugged in and out my USB device.

Because of this behaviour, I couldn’t read any data from my USB devices. I am powering up the USB HUB from an external source so power shouldn’t be the problem and the device is perfectly working on another Ubuntu machine.

I am only able to detect the USB devices port if I don’t use a USB HUB which is useless since I have to use more than one devices.

All in all, I am asking for communities help about it.

2

Are you connecting these devices to the Jetson’s USB? If so, then monitor “dmesg --follow”, and observe what is produced as the HUB is plugged in. The observe what shows as devices are plugged into the HUB. Follow this with the tree view output of lsusb:
lsusb -t

Note that serial devices over USB will be visible by lsusb even if there is no driver for the specific device. To produce a “/dev/” entry there must be a second driver…one for that serial UART chipset. The above information will probably reveal more about what is going on, and what driver the UART requires. Or if there is an error.

3

Thank you for your answer. I am connecting devices to the Jetsons USB. I tried the commands you suggested both on Jetson an on a regular Ubuntu Computer. It turns out problem is not related with the USB-HUB. As you mentioned it is an driver problem.

When I type “lsusb -t” on a regular Ubuntu device, I observed that the RS232 to USB converter uses a driver called “ti_usb_3410_5052”. When I try the same on Jetson the driver section of is empty.

I searched for it and found a driver for the usb converter but when I try to install it I faced with the following error:

Unable to locate matching source for kernel 4.9.140-tegra+.
Please refer the readme.txt to install proper kernel-header/source.

Makefile:72: recipe for target ‘envchk’ failed
make[1]: *** [envchk] Error 1
Makefile:16 recipe for target ‘install’ failed
make: *** [install] Error 2

Here is the source of driver I found:
[USB-to-Serial Converters - Industrial USB-to-Serial Converters | Moxa](http://usb-hub drivers)

4

USB is only a pipeline, and a second driver is needed for the actual device. Some devices have industry standard generic drivers, e.g., for a keyboard or mouse, but many others require a driver for the chipset or other hardware. Basically, your next task is to add a driver.

You already know that your desktop Ubuntu PC has the driver, and thus if you identify which driver is being used on the desktop, then you will probably be able to build this as a kernel module and simply copy the file to the right place and have it work. The key to that is knowing the “symbol” to configure and then compiling the module from the regular kernel source after setting up a configuration match to the currently running kernel, but with the additional symbol enabled for that driver.

I probably made it sound more complicated than it is, but with one exception, your Jetson’s current configuration is its “/proc/config.gz” file. You’d copy it to somewhere else (and I recommend keeping an original around somewhere without edits), gunzip it, and rename it as “.config”. When placed at your kernel compile directory this will produce nearly an exact match for your running system.

That file is plain text, and you would not normally edit this directly since there might be dependencies, but one line will have “CONFIG_LOCALVERSION”. You’d have to edit this one line, and then the config would a 100% exact perfect match to what you are running (I am assuming you are already running a default NVIDIA kernel):
CONFIG_LOCALVERSION="-tegra"

You’d need to read some kernel compile docs, but basically then if you were to enable a feature/symbol via some variation of “make nconfig”, then you’d be set for building that driver. Should the driver be integrated into the kernel things get more complicated, but if the driver is a module, then all that is left is basically to copy the module file to the correct subdirectory of:
/lib/modules/$(uname -r)/kernel/

Note that “uname -r”, as a command, has the suffix from CONFIG_LOCALVERSION. If your CONFIG_LOCALVERSION is not a match for what it was previously, then the kernel won’t be able to find any of the modules and you’d have to reinstall all of them to a new location. If base configuration matches, and uname -r matches, then things just fall in place without much effort.

The key to all of this, if the driver exists but simply was not configured, is to know the name of the feature. The symbol. This is why I suggest using whatever loaded in the host PC to find what module it is using. Otherwise you could do a web search and research this. However, if that device is being used on the host PC, then the command “lsmod” will show you what modules are being used. Some of the text you see if you run “dmesg --follow”, and then connect the device, in combination with the modules, will lead you directly to that answer.

Can you see which module your desktop PC uses when the device is plugged in? Wait until after boot to plug the device in, perhaps running “lsmod” before and after the device insert, and comparing the list to see what is new. Or the “dmesg --follow” will probably indicate something like the name of the module.

I just went through that so you would know, but FYI, the symbol will turn out to be ’ CONFIG_USB_SERIAL_TI’. Check this from the Jetson:
zcat /proc/config.gz | grep 'CONFIG_USB_SERIAL_TI'

5

I have been trying to follow these steps for a few days yet I couldn’t manage to succeed. I am trying to install the following driver. It is a module named “ti_usb_3410_5052”. I am really confused about your answer. Could you please explain for a nooby?

moxa-uport-1000-series-linux-kernel-4.0-for-uport-11x0-series-driver-v4.0.tgz.zip (100.0 KB)

6

Your attached file is for a third party driver which is not shipped with the Linux kernel. My earlier reply mentions ’CONFIG_USB_SERIAL_TI’, which might do the same thing, but ships with the Linux kernel source (you can call this “in tree source”). I don’t know if the ’CONFIG_USB_SERIAL_TI’ driver will work for your case, but it might (I saw some indications on the internet where ’CONFIG_USB_SERIAL_TI’ is a possible solution…perhaps both drivers do the same thing, perhaps not). The symbol (the “CONFIG_” name) describing the driver you have attached as a separate source is ‘CONFIG_MOXA_UPORT_11X0’ (described in the README file). One can refer to a driver by its symbol. The symbol is how the kernel “kconfig” configuration system refers to drivers or features.

Regardless of whether you use external source ‘CONFIG_MOXA_UPORT_11X0’ (which would be “out of tree source”), or built in source from ’CONFIG_USB_SERIAL_TI’ (“in tree source”), you would start by configuring your source code to be an exact match to your running system. This is related to using either the content of “/proc/config.gz” (in combination with setting CONFIG_LOCALVERSION="-tegra"), or using “make tegra_defconfig” and the same CONFIG_LOCALVERSION edit (the former config.gz method is preferable if your kernel has not been edited).

Note that some kernel features depend on other features. Some kernel features are incompatible with other features. The “kconfig” system is how feature dependencies are tracked. Unless we are talking about the same configuration across two builds we are not talking about the same kernel even if the source is the same. We always start with two matching configurations prior to editing in changes.

When you build a module against a kernel which is not shipped with the kernel it is called “building out of tree”. This is described here by official kernel.org docs, but keep in mind you would still download and configure the source code to match your current system prior to performing an out of tree build:
https://www.kernel.org/doc/Documentation/kbuild/modules.txt
…and that source code must be from the release used to build your kernel originally. Very likely Orbitty uses the exact kernel from the L4T release version, but could possibly have some minor config differences.

The kernel is really a very large number of possible source code, and unless the configuration matches, then two kernels built from the same source code are likely very different (incompatible) kernels. Thus your first goal is always to build a standard kernel which is an exact match to your current running system.

Is your current kernel the default kernel which came with the Jetson install?

Just to emphasize, unless you know ’CONFIG_USB_SERIAL_TI’ is the wrong driver, I would attempt to build a kernel module for this first and try it (you’ll need the kernel source regardless of which driver you test, but this driver is already in the source code and is thus easier to test).

Once any kernel module is built the testing is basically just a file copy, testing if the module can be loaded, and then plugging in your device and testing. If you were to use the “out of tree” symbol ‘CONFIG_MOXA_UPORT_11X0’, then actual module install would be the same thing more or less, but the file name you’d copy into place would be different than the ’CONFIG_USB_SERIAL_TI’ file.

The README file which comes with the source code you attached is expecting the full kernel source at “/usr/src/<kernel-source directory>”, and you would need to adjust for the different location of source code since this is not for the PC. Some of the instructions will also change depending on whether you are cross compiling from a PC versus performing a native compile directly on the TX2. Some questions about this:

  • Are you cross compiling (from the PC), or are you native compiling (from the TX2)?
  • Is your running kernel on the TX2 modified, or is it the stock kernel?
  • On the TX2, what do you see from “uname -r”?
  • Do you see files from “ls /lib/modules/$(uname -r)/kernel/*”?
  • Where did you obtain the full kernel source from, and where did you install it to in preparation for the module build/compile?

Note that I do not know if the Orbitty uses a modified kernel or not. If you have the working Orbitty with its default kernel, then the file “/proc/config.gz” should be copied to some safe location as this is the kernel telling you its exact configuration (this file is not a real file, this is RAM running in the kernel pretending to be a file). Knowing the above will allow more specific advice.