Jetpack 6.0 doesn't include the ttyUSB driver

I need to use Jetpack 6.0 for TensorRT, but even after reinstallation, it’s not working, so I’m looking for a solution. A similar case was discussed here: Orin nano wont detect arduino /dev/ttyUSB* or /dev/ttyACM* - #20 by linuxdev, but it hasn’t been resolved yet.

Previously, there was a method suggesting to comment out the port number 2303 in 85-brltty.rules, but there was no 2303 listed. (We’re using PL2303.)

How can I make sure that ls /dev/ttyUSB0 shows up? I suspect that Jetpack 6.0 doesn’t include the ttyUSB driver. How can I resolve this issue? I have checked with Jetpack 5.1.3, and ttyUSB0 showed up fine.

Thank you.

I have same issues in jetson orin nx 16gb, jetpack6.0.

1 Like

You’ll need to describe your exact issue since even tiny differences might matter. Also, is this a dev kit, or does this use a third party carrier board?

Meanwhile, some basic information might help as a place to get started…

The files “/dev/ttyUSB*” and “/dev/ttyACM*” are serial UART files which result from having a particular brand of USB-to-serial-UART chipsets. One brand results in ttyUSB* when pluggging it in to USB, the other brand results in ttyACM* when plugging it in to USB.

USB devices are “plug-n-play”. Those devices can self-describe as to what they are upon plugin. When a plug-in event occurs, the hot plug layer will broadcast the device’s description. Other than this, the USB side is just a data pipe and has more or less done its job. The drivers which see this hot plug event have the choice to take ownership of the device. If you have both of the drivers for the two brands of serial USB UART chipsets, then each driver will know descriptions it can take ownership of, and ignore plugin events for other types of devices.

Normally USB works, but people tend to think USB failed when something goes wrong. Two things can go wrong: (A), the driver is not present, and so hot plug can’t hand ownership over (the driver won’t take ownership), or (B) there is no association between the driver and the description provided by the device. The latter is typically the case when a company uses a standard chipset but rebrands it such that you need a new association rule for the rebrand that binds the device to the driver. The former argument, (A), is usually not the case on Jetsons, because normally they have those drivers. If not, then it isn’t broken USB. You can get an actual USB error due to signal quality issues, and this does happen.

To distinguish between those errors you probably need to monitor “dmesg --follow”. This continuously views the kernel log. Then plug in the USB device. The log lines which occur as a result of that plug in event will answer which of those errors is at fault (you don’t need the log lines which occur prior to this).

I’ll add a different error which is specific to USB (not to hot plug), but which does not normally occur: If you have the wrong firmware due to flashing with NVIDIA software when the carrier board is really from a third party, then USB itself tends to not be found correctly by the USB drivers. The USB root HUB is itself not plug-n-play, it sits at a physical address on a bus, and the firmware is how the kernel is told where the root HUB is at. Custom carrier boards tend to use a different layout by means of the I/O assignments to pins being flexible to aid in easier carrier board layout.

So what we need is for you to run “dmesg --follow”. Then plug in the USB device, and post what log lines occur as a result of the plugin event. Also, we need to know if this is a third party carrier board, or if it is a dev kit. Finally, we can use the software release that is running, which you can find via:
head -n 1 /etc/nv_tegra_release

If you don’t know if this is a dev kit or not, then you might post the output of “cat /etc/nv_boot_control.conf”.

Note that 85-brltty.rules is one of those rules which associates custom hardware to particular drivers. Unless this is the related Braille hardware, then it is unlikely you will change anything by removing or adding Braille driver associations.

Thank you.
When I typed in the command you gave me, it showed up like this.

dmesg --follow

[  130.114938] usb 1-2.1.2: USB disconnect, device number 7
[  136.737340] usb 1-2.1.2: new full-speed USB device number 10 using tegra-xusb

head -n 1 /etc/nv_tegra_release


# R36 (release), REVISION: 3.0, GCID: 36191598, BOARD: generic, EABI: aarch64, DATE: Mon May  6 17:34:21 UTC 2024

cat /etc/nv_boot_control.conf


TNSPEC 3767-300-0000-M.1-1-1-jetson-orin-nano-devkit-
COMPATIBLE_SPEC 3767-000-0000--1--jetson-orin-nano-devkit-
TEGRA_BOOT_STORAGE nvme0n1
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0

lsusb

Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 413c:301a Dell Computer Corp. Dell MS116 Optical Mouse
Bus 001 Device 004: ID 413c:2113 Dell Computer Corp. KB216 Wired Keyboard
Bus 001 Device 009: ID 058f:6387 Alcor Micro Corp. Flash Drive
Bus 001 Device 008: ID 1e4e:0100 Cubeternet WebCam
Bus 001 Device 010: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P
Bus 001 Device 005: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey]
Bus 001 Device 003: ID 214b:7250 Huasheng Electronics USB2.0 HUB
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Hi,
On Jetpack 6 the defconfig is aligned with upstream kernel, so certain configs are not enabled by default. Please check if your device works on Jetpack 5.1.3. And compare the configs with Jetpack 6.0GA to identify which configs have to be enabled for the device. And you may share brand and model ID of the device. Other users may have the same device and can share experience.

It works well on Jetpack 5.1.3. Could you please explain in detail how to compare the configs to identify which configs need to be enabled for the device? The device is this one, but when I searched for it and tried the solutions I found, none of them worked, so I have been formatting it repeatedly.

USB disconnect occurs from unplug, so that isn’t of particular use. However, this says USB indeed did see the plugin:

[  136.737340] usb 1-2.1.2: new full-speed USB device number 10 using tegra-xusb

Was that the only log line which occurred as a result of plugin? If so, then:

  • No driver was associated with the device, or the driver was missing and thus no association.
  • Sometimes logs show a manufacturer and device ID, but that is missing.

I don’t need the full lsusb logs, but what I’m interested in is if you compare “lsusb” without the device connected, and then again with it connected; which lsusb line shows up as a result of having the device plugged in during lsusb? There should be exactly one extra lsusb device shown when your device is plugged in, and that would give us IDs. Your current lsusb has a lot of devices listed and I don’t want to guess which one it is (and the device might even be missing).

However, on any other Linux computer in which this works, you could also get the log lines of what “dmesg --follow” adds upon insertion to USB. This might tell us a bit more and might even be preferable. This would identify the device and perhaps also the driver. If that log line also says the new device special file is “/dev/ttyUSB0” (or similar), then this tells us which driver because that naming is paired with a chipset’s driver.

Note: What @DaneLLL says makes sense too. The R36.x L4T (which you have installed) using the mainstream driver does not enable anything that the mainstream does not enable in its defconfig. NVIDIA did not design this kernel’s config, whereas in earlier L4T (the L4T R35.x from JetPack 5.x) is designed by NVIDIA (well, the config and some out of tree content is configured by NVIDIA). The above questions should answer what driver to enable.

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