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):
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:
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'