UART0 Debug - Flow Control


Are flow control signals (CTS/RTS) necessary for debug purpose using UART0 on Jetson TX2?


No. Default is 115200 8N1 with no hardware flow control (CTS/RTS are not used for the default case).


Thanks linuxdev.

The UART0 is only for debug purposes?
Can UART0 be used for SSH over serial?

Instead of speaking of UART0, I will say that if the device special file (e.g., “/dev/ttyS0” or “/dev/ttyTHS0”) is group “tty” (and not group “dialout”) when used as a console. This is from the software which runs as a console. Non-console device special files will never show as “console”. Example:

# ls -l /dev/ttyS* /dev/ttyTHS*
crw--w---- 1 root tty       4, 64 Feb  9 11:37 /dev/ttyS0
crw-rw---- 1 root dialout   4, 65 Feb  9 11:37 /dev/ttyS1
crw-rw---- 1 root dialout   4, 66 Feb  9 11:37 /dev/ttyS2
crw-rw---- 1 root dialout   4, 67 Feb  9 11:37 /dev/ttyS3
crw-rw---- 1 root dialout 238,  1 Feb  9 11:37 /dev/ttyTHS1
crw-rw---- 1 root dialout 238,  2 Feb  9 11:37 /dev/ttyTHS2
crw-rw---- 1 root dialout 238,  3 Feb  9 11:37 /dev/ttyTHS3

In the above everything is available except the one with group “tty” ("/dev/ttyS0"). If the serial console software were to stop running on “ttyS0”, then group would revert to “dialout”, and this would then be usable by anyone.

Which tty corresponds to UART0 I don’t know (depends on hardware and device tree).

An important detail though is that the “ttyS#” entries use a legacy driver, and the “ttyTHS#” entries use the NVIDIA “Tegra High Speed” driver (which uses DMA). A ttyS of the same number as the ttyTHS is the same hardware, but run with different drivers. You would only use one at a time, and the reason why the serial console uses a ttyS and not a ttyTHS is because during boot steps prior to Linux running only the legacy driver is available.

Note that if you disable serial console in Linux that the “console” group disappears from the “ttyS” or “ttyTHS”, but in boot stages prior to Linux running this is not true. Those earlier stages are their own mini operating system (the bootloader) and would have to be disabled separately. One would typically disable serial console in Linux via something like “sudo systemctl disable nvgetty.service”, but activity on that serial UART in earlier boot stages could still occur from console.

The device tree would be the content to change if you want a permanent change or disable of serial console. Serial UARTs are not “plug-n-play”, and thus cannot self-describe, but are instead manually described to the bootloader and operating system via device tree. There will be an entry like this:
serial@<hex address>

Within that will be a “compatible” node which names which drivers are allowed. Example if both are allowed (but this only allows the driver, other software can pick the driver):
(two drivers are available for the device, and it is a comma-delimited list…the hsuart is the THS device special file generator)

To see what arguments the device tree passes to the kernel (this is a TX2):

# cat /proc/device-tree/chosen/bootargs
root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid= maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

If you then look at “/boot/extlinux/extlinux.conf”, then you will see “${cbootargs}” in the “APPEND” key/value pair. This inherits the content of “bootargs” in the device tree. This content, when passed to either bootloader or Linux kernel, says which UART to use as a serial console:
(and the physical UART depends on the “serial@<hex address>”)

Here is a information on disabling serial console:
(it is not advised to remove serial console access…changing to a different UART is more useful)

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