Try to prepare the usb serial communication of Orin, but ttyUSB* or ttyACM* is not displayed on the device. You can see the corresponding usb device through lsusb command. Why is there no ttyUSB*? Why is it on x86 PC?
What is the exact platform here? You filed a topic on Orin but you also mentioned TX2.
Are you saying that you want to dump Orin’s log from TX2?
The USB camera was recognized by lsusb, but there was no ttyUSB* after running ls -l /dev/tty*. Is it because Orin didn’t pre-install CH341 and CP210x drivers? How can I install them on Orin? Thank you
I’m sorry. My platform is AGX Orin. I have been troubled by this problem for several days. Do you know how to solve it? Any reply will be grateful.
Some related information: The presence of any “
ttyUSB*” (or any other “
/dev” file, e.g., from CH341 or CP210x) implies a driver loaded for that particular brand of serial UART. The naming would depend on the brand of hardware, e.g., so far as I know, only an FTDI serial UART uses “
/dev/ttyUSB*” naming. Lack of a device after plug-in probably means no driver installed for that chipset. To see what is visible you would want to run “
dmesg --follow”, and then observe what shows up in logs as you plug in your USB device. Then post that log here.
Incidentally, a PC pretty much adds drivers for all kinds of things you wouldn’t want to automatically load in an embedded system. The space requirements are not often a limitation for a PC, but inefficient addition of unused drivers on a small disk is usually frowned on for small systems. Adding drivers for hardware not present is in general a bad idea. Now that the hardware is present, the issue is knowing how to manually install the driver (this is where different distributions and operating systems differ: Automatic or manual driver install steps).
這一個問題裡面到底是有tx2跟Orin 還是只有 Orin？ 到底是想要用哪種裝置來產生/dev/ttyUSBx?
Sorry that I still not get what you want to ask here.
Is this issue related to TX2 and Orin or only Orin? And what device are you using to generate the /dev/ttyUSBx node?
Hello, WayneWWW! There is only Orin in this question. I want to use it to generate /dev/ttyUSBx.
所以你是在問說為何Orin沒辦法在你的x86 PC上產生/dev/ttyACMx 或/dev/ttyUSBx 這些node嗎
So you are asking why Orin is not able to generate /dev/ttyACMx or /devttyUSBx on your x86 PC?
不是，我的意思是当我把我的USB相机连接在Orin上时，Orin无法产生/dev/ttyACMx 或/dev/ttyUSBx 這些node。
而当我把USB相机连接在X86的台式电脑上时，可以看到/dev/ttyACMx 或/dev/ttyUSBx 這些node。
我想知道如何在Orin上产生/dev/ttyACMx 或/dev/ttyUSBx 這些node？
I mean when i connect my USB camera to Orin, Orin can’ t generate /dev/ttyACMx or /dev/ttyUSBx node.And when i connect a USB camera to an X86 desktop, i can see /dev/ttyACMx or /dev/ttyUSBx as node.I wonder how to generate /dev/ttyACMx or /dev/ttyUSBx node when the camera is connected to Orin. thank you
dmesg (76.2 KB)
Thank you. Attached is the dmesg file I saved.
The problem I faced on Orin also appeared on my friend Xavier, and he solved it according to the method of jetsonhacks (GitHub - jetsonhacks/buildJetsonXavierKernel). But there isn’t any solution about Orin there.
你可以先把你的usb camera插到x86 host上面然後看一下x86的dmesg是哪個driver把/dev/ttyUSBx給建出來的
You can add your usb camera to x86 host and check what driver is creating the /dev/ttyUSBx node. I think Orin may not have that driver installed.
dmesg.txt (96.0 KB)
Hi, 我把usb camera插到x86 host上面后，得到的dmesg在附件中。
Hi, after I plugged the usb camera into the x86 host, the dmesg is in the attachment.
please run “sudo modprobe usebserial” on your orin and plug the usb device again.
Hi, WayneWWW, thank you! I did as you said, ran sudo modprobe usbserial "and plugged in my usb camera. But it doesn’t seem to be working properly yet. Dmeag’s tail is in the attachment.
dmesg (705 Bytes)
I plugged the usb camera into x86 desktop computer and AGX Orin respectively, and recorded their output information in the attachment.
Output.txt (3.9 KB)
One thing I don’t understand is that if you see a “
/dev/ttyUSB*”, then it is from an FTDI chipset driver, but if you see “
/dev/ttyACM*”, then it would be from the CDC_ACM driver. All of your computers seem to have this error upon plugin, and do not mention FTDI in any way:
[13423.263973] cdc_acm: probe of 1-4.1:1.2 failed with error -22
I’m thinking that perhaps the
ttyUSB* you see is not from that camera? Also, the CDC_ACM might have failed inside the camera if this is part of the camera. I say this since all systems, Jetson and PC, have the above error. One would expect “
/dev/ttyACM*” for that particular device.
Adding some detail to what @WayneWWW already mentioned, it looks like there are actually several modules related and in need of simultaneous load:
usbcore.ko uhci-hcd.ko ohci-hcd.ko or ehci-hcd.ko cdc-acm.ko
Try to modprobe each of those if they do not show up in “
lsmod” (though no module would exist if it happens to be built in to the kernel).
I also found an interesting URL on the return code -22 error:
Also, with the device plugged in to the Jetson, what is the exact output of both “
lsusb” and “
usb-devices”? I ask because it will show the ID of vendor and device, and might be used (as explained in the above URL) during module insert to specify a specific device if a general device insert does not succeed.
Finally, is it possible the FTDI serial device (the “
/dev/ttyUSB*” naming convention) is not from this device?
hi, linuxdev! Thank you。 I’m sure ttyUSB0 appeared after my camera was connected. The attachment is the output information obtained by inputting the same command on X86 and Orin.In fact, the error that I encountered that does not display ttyUSB* or ttyACM* on Orin has also been encountered by many TX2 users (NVIDIA Jetson TX2内核添加串口驱动_柳絮的独白的博客-CSDN博客? spm=1001.2101.3001.6650.2& utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-2-79253483-blog-118966458.pc_relevant_3mothn_strategy_recovery& depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-2-79253483-blog-118966458.pc_relevant_3mothn_strategy_recovery&utm_relevant_index=3）。They analyzed that this is their Jetson TX2. By default, the relevant drivers of usb serial port are not added, so it needs to be checked manually.They downloaded the source code from the buildJetsonTX2Kernel warehouse (GitHub - jetsonhacks/buildJetsonTX2Kernel: Build the NVIDIA Jetson TX2 Kernel on the device itself) of JetsonHacks Github, and added the serial drivers CH341 and cp210 to the kernel compilation interface, and then fixed it.Therefore, I want to follow their ideas, but I haven’t found any warehouse of buildJetsonOrinKernel in JetsonHacks Github. I don’t know how to add CH341 and cp210 serial drivers in Orin. Any guidance would be greatly appreciated.
Adding drivers as a module format is reasonably simple. If you were to build these integrated directly into the kernel, then it would get more complicated. The official docs which come with the specific L4T/JetPack release would be what you would go by for cross compiling. Just be sure you don’t “flash” the modules in place since only a copy of files is needed if the main kernel is not rebuilt. You’d look at the “kernel customization” part of the documents for how to cross compile.
I’m going to add that if you start by perfectly matching the existing kernel’s configuration, and then using one of the editors for adding the required modules, any new modules you create simply “fit in” and work without effort.
Jetsons normally ship with a configuration of the kernel known by the build target “
tegra_defconfig”. If the kernel was never modified, then that could be the starting configuration, followed by adding the configuration for the new modules. A running Jetson also shows its idea of what the kernel config is via the file “
/proc/config.gz”. In theory, if nothing is modified, then that file is the compressed equivalent to target “
tegra_defconfig”. I tend to skip “
tegra_defconfig” and go directly to using “
config.gz” (first uncompressed, and then renamed as “
.config”, and placed at the right location during a kernel build) since it will always match what is running regardless of whether it is stock config or not.
Pay close attention to the output of “
uname -r” on the Jetson. No doubt it will provide the kernel version plus suffix “
-tegra”. In any “
.config” file used for configuration (which is what make target “
tegra_defconfig” also produces) you will find this line (it is human readable text):
You’d want to match that suffix and edit that line to be:
(there are actually multiple ways to do this)
Once that is set up you are ready to build modules (actual instructions give details, I’m just supplementing that here). One would propagate the configuration with the make target “
modules_prepare”, then you’d build “
modules” (explained in the kernel customization), and you’d have the files in need of copy (no flash needed).
You can always ask more questions if the kernel customization docs are insufficient.
Note that you can see your L4T release via “
head -n 1 /etc/nv_tegra_release”. You can go to the particular L4T URL by picking from this list:
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.