I am only answering a tiny subset of your questions. Be sure the “group” of “/dev/ttyTHS0” is “dialout”, and not “tty”. Note that “/dev/ttyS0” is the exact same hardware as “/dev/ttyTHS0”, and that the different device special files are only because there is both a legacy driver and a Tegra High Speed (with DMA) driver (you wouldn’t use both at the same time). If either the ttyTHS0 or ttyS0 have group tty, then it means serial console is running on that port. Here is an example:
# ls -l /dev/ttyTHS* /dev/ttyS*
crw--w---- 1 root tty 4, 64 Oct 22 13:51 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 Oct 22 13:51 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Oct 22 13:51 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Oct 22 13:51 /dev/ttyS3
crw-rw---- 1 root dialout 238, 1 Oct 22 13:51 /dev/ttyTHS1
crw-rw---- 1 root dialout 238, 2 Oct 22 13:51 /dev/ttyTHS2
crw-rw---- 1 root dialout 238, 3 Oct 22 13:51 /dev/ttyTHS3
Notice in the above example that ttyS0 and ttyTHS0 is the same UART, and that because ttyS0 shows a group of “tty” instead of “dialout”, the implication is that you cannot use either ttyS0 or ttyTHS0 unless you disable serial console. In many cases, if one of the other UARTs are accessible, it would be preferred to use the different UART rather than disabling serial console (especially if you are developing).
A typical temporary disable of serial console (but only after booting…this would leave boot content still using the console, which is why disabling serial console is a bit more difficult than changing UARTs) would be “sudo systemctl stop nvgetty.service”. Actually disabling this across boots would be “sudo systemctl disable nvgetty.service”, but remember that this only takes effect when Linux runs (there would still be serial console in bootloader stages, and disabling serial console in those stages is more invasive).
A typical way to test a serial console is to loopback wire its TX to its own RX. Then you could echo to the device in one place, and cat from the device in another place and the echo should appear on the cat. Or you could run a serial console program (such as minicom or gtkterm) and whatever you type in should echo back.
Do note that on non-loopback both ends need to be 3.3V logic level for the UART, and both need the same settings. The default setting is 115200 8N1. Loopback is nice because one device always agrees with itself for voltage level and port settings (unless something truly bizarre is going on).
Also, you might want to avoid flashing if you are just changing a kernel. The kernel from the “/boot” takes priority over the kernel in the partition if the extlinux.conf names the kernel. There are probably some advantages to also flashing the kernel to a partition on the Jetson models which use U-Boot (such as the TX2 dev kit), but it isn’t mandatory. If I were to flash the content to the partition I would also use file copy into “/boot” and make sure both use the same kernel so that no matter whether it is extlinux.conf or defaults picking a kernel they’d be the same.
Setting up a UART never requires flash on Jetson. Kernel changes go beyond setting up a UART, and this involves driver changes, so changing the driver probably does warrant better terminology than just “settings”. However, if the driver is not truly being changed, but only the arguments passed to the driver are changed, then the implication is that the device tree would instead need editing, and this does not require changing the kernel or drivers. A device tree is essentially a set of arguments passed to a driver for non-plug-n-play devices.
You can always ask more.
