Could you share any insights/ suggestions/ solutions, please?
For setting baudrate of a port [UART] ttyTHS0, please?
So that it will boot OS with specified baudrate?
The below assumes you mean serial console, but if you mean a tty for a non-serial-console purpose, then details would help (e.g., what speed).
I haven’t actually tried this, but the UART speed may need to be set in both bootloader and Linux. If you want to make it slower, then this would be easier than making it faster.
For the bootloader, perhaps the device-tree’s “chosen->bootargs” would do the job, and maybe this would be sufficient since it passes along to the Linux kernel. This particular token says what speed to use:
console=ttyS0,115200n8
Whether or not the actual UART will change its settings with that I’m not sure, but it is easy to test.
Note that faster speeds beyond 115200 will often require two stop bits since the clocks won’t select the exact required clock speed (two stop bits apparently relax timing requirements).
Note that “stty” can be used to set up speeds, at least within Linux. Example for 115200 with 1 stop bit (see the “man stty” information…stty is a bit odd…bad pun intended):
stty -F /dev/ttyTHS2 115200 -cstopbit
@linuxdev thank you for your reply!
the problem emerged from Time sensitive networking [TSN] on NX - #112 by _av
I was trying to get ntp server to autostart; I was able to do so, but it wouldn be able to read from UART only if the baudrate is set.
I was able to change it on started system from terminal with /bin/stty -F /dev/ttyTHS0 38400
but systemd, rc.local and other autostart methods wouldn’t work for setting up baudrate.
I can check it on running system with
cat /dev/ttyTHS0 unless baudrate is set there will be no readable inputs from GPS UART output
I wonder if it is too early in boot for that to be set up? If you look at the device, then there are two possible drivers for that same hardware. One creates “ttyS0”, the other creates “ttyTHS0”. For serial console support is required in early boot stages, and the “Tegra High Speed” (THS) does not exist there, so it uses “ttyS”. Once Linux runs, serial console remains on “ttyS”…thus there is no need to reload the other driver (I suppose you could try to use both ttyS and ttyTHS at the same time, but I think at best the results would be unpredictable). However, the point is that ttyTHS does not load as early. ttyS won’t load early either unless something sets it up, and the reason for that setup being early is for serial console support. Your use of a ttyTHS may in part fail if the driver has not yet loaded.
exactly!
yet all attempts failed
If you are looking at a particular UART, then it might be interesting to look at a serial console boot log, and grep for that UART. For example this would search for both ttyS0 and ttyTHS0:
dmesg | egrep 'tty(S|THS)0'
Then look at the timestamp and compare when the attempt to use the UART occurred relative to the UART being set up.