I want to find serial driver for ues in Linux ,what can i find from?
You could refer to 8250 driver (kernel/kernel-4.9/drivers/tty/serial/8250/8250_of.c).
Why only have ttyTHS0,ttyTHS3,ttyTH4, don’t have ttyTHS1,ttyTH2
My Jetson Orin Nano only have ttyTHS0 ,ttyTHS3,ttyTH4, don’t have ttyTHS1 ,and ttyTHS2,how to find them?
Are you using Jetson Nano or Orin Nano…?
They are just the node under /dev and depending on the actual use by different driver.
You should know how many UART interfaces included on your board first.
Please refer to the carrier board specification for details.
Intotal three UART interfaces,my UART1 → ttyTHS0,and UART0 was originally used by WIFI,I have uninstalled the WIFI module and driver, and want to use UART0 as an ordinary output serial port. Can you tell me how, Bro?
I don’t think that particular UART can be used for general purpose, but some background information you might be interested in follows…
Jetsons come with all drivers for every integrated UART, and then some on top of that. The normal reason for not working is that the device tree has to be set up correctly for a driver to find the UART. Some devices are plug-n-play, and they can self-report; UARTs are not plug-n-play, unless they go through something like USB or PCI (in which case it is part of the USB and it isn’t really the UART which is plug-n-play, it is the USB added content). Most of the time the driver has to be told where to find a UART (a physical address), along with what driver applies to that UART. If a UART is present at some physical address (not USB or PCI), and if the device tree binds the driver to that address, then it will work. If not, then the driver won’t load.
It is the driver loading and finding hardware that results in the “/dev” file. Those are not real files. The naming convention depends on the particular driver (and sometimes by a udev rule renaming it). The integrated UARTs on a Jetson can have either a legacy driver (the 8250/16550A style) bind to this, or they can have the NVIDIA “Tegra High Speed” driver bind (which uses DMA). If the name is “/dev/ttyS#” (the # being a number), then the driver is the legacy 8250/16550A (there are actually some older legacy modes which can also be used, but the naming convention remains the same). If the device special file is naming convention “/dev/ttyTHS#”, then it is using the NVIDIA UART driver.
Both drivers can exist at the same time. The same physical I/O pins can have both a ttyS# and a ttyTHS# driving the same UART. You would not want to use both simultaneously. Sometimes there is an advantage to the legacy driver, mostly if it is needed in boot stages before Linux loads (e…g, a serial console in boot stages which uses a ttyS#, and then switches over to ttyTHS# once in Linux might lose some log line during the switch from legacy to DMA; most boot software does not have a THS driver).
If you don’t have a THS driver for one of NVIDIA’s UARTs, then the device tree is not set up for it. If the device tree is not set up for it, then sometimes it is because the internal wiring does not make itself visible to the carrier board. I suppose it is possible that the Wi-Fi UART can be routed to an external pin via device tree, but so far as I know this is not possible.
1 Like
You could refer to the UART part in design guide.
It seems you want to use UART0 (which is routed to M.2 Key E).
If you want to use this UART0 for custom usage, you should solder them with your UART device by yourself first.
Please share the full dmesg for further check.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.