Jetson TX2 L4T version：
cat /etc/nv_tegra_release
# R32 (release), REVISION: 4.3, GCID: 21589087, BOARD: t186ref, EABI: aarch64, DATE: Fri Jun 26 04:34:27 UTC 2020
Question 1：
In the /dev directory, there are so many serial device nodes like ttyGS0, ttySx, ttyTCU0, and ttyTHSx. I now know the debugging serial port UART0 (H12, G12) used by ttyS0. ttyTHS2 corresponds to UART1 (D9, D10) on J17. The other device nodes correspond to those serial ports. What does it work for?
Question 2：
Our customized hardware uses UART7 (D5, D8), which device node this serial port corresponds to, or what needs to be modified to generate a new device node.
hello qulei159,
Jetson TX2 bring five UARTs out to the main connector,
please access Jetson TX2 Series OEM Product Design Guide, and check chapter [13.3 UART] for more details.
thanks
hello qulei159,
please also check discussion thread, Topic 153941,
it shows an example of mappings for serial ports of ttyTHS*, and UART*
thanks
Just as general information, the naming depends on the driver, plus possibly udev. Typically a USB based serial UART from FTDI (the most “out in the wild” UART) has a name like “/dev/ttyUSB#”. Jetsons usually have two drivers to pick from for their serial UARTs which are integrated: The one with a naming convention of “/dev/ttyS#” is the traditional Linux driver, whereas the naming convention with “/dev/ttyTHS#” uses NVIDIA’s driver…on the same UART.
So ttyS0 and ttyTHS0 are typically the same UART, but accessed by different drivers for the same hardware. Don’t use both at once.
UARTs from third parties will have their own naming convention based on chipset, e.g., like what I mentioned for the ttyUSB# names. The driver does this since device special files are not actually files…they are an interface to a driver pretending to be a file.
Hot plug devices tend to also sometimes be renamed by “udev”. udev can read rules as hot plug devices connect, and rename them or set up preferences. Just as a contrived example, look at device special files on your desktop PC at “/dev/input”. This would be for human interface devices (HID class in USB), e.g., keyboards, mice. Notice there are subdirectories “/dev/by-id” and “/dev/by-path”. Within those subdirectories the same device gets symbolic links pointing to the original device name. This is udev triggering rules to add multiple names using alternate naming conventions. Sometimes udev will actually rename a device completely, but adding alternate names is a good example of what udev rules can do.
hello:
I added the following code to the device tree:
serial@c290000 {
compatible = “nvidia,tegra186-hsuart”;
dma-names = “tx”;
status = “okay”;
};
Recompile the device tree and replace it. UART7 (D5, D8) is enabled, and it can be seen that the ttyTHS6 device node is generated through the dmesg information.
Through the serial port tool test, it is found that ttyTHS6 sends data normally and cannot receive data. The serial port tool always echoes the data sent to ttyTHS6.
When tx2 is started, this serial port has debugging information output, and then you can input commands (and echo function). After the linux kernel is started, the serial port is enabled according to the device tree configuration. At this time, is the echo function of the startup phase inherited?
I need to use this serial port as a communication serial port. How can I disable the echo function?
hello qulei159,
please also check developer guide, Disable Console over UART.
BTW,
UART-7 is used for BPMP debugging by default, you may also modify the BPMP dts.
please check discussion thread, Topic 54572 for the steps of enabling UART-7 as see-also.
thanks
Just a reminder: Don’t forget DMA on both tx and rx, e.g.:
dma-names = "rx", "tx";