Unable to access /dev/ttyTHS0

I want to use the serial port on the 40 pin header as a UART connection for my motor controller. Grounds are connected, Rx to Tx and vice versa is in. I can access the serial commands just fine with screen if I apply sudo, since the permissions on /dev/ttyTHS0 are so weird.

$ ls -l /dev/ttyTHS0
crw--w---- 1 root tty     238, 0 Dec 21 13:12 /dev/ttyTHS0

screen doesn’t work on this port, but sudo screen does. If I run sudo chmod 666 /dev/ttyTHS0, I can run screen without sudo. However, I seem unable to run this chmod command on startup through any means I have yet to try, not to mention that it seems like a fishy way to solve this problem. What is the proper way to get access to the UART ports on an AGX Xavier?

Note that the “group” of this port is “tty”. Other software is already using this port (the serial console program). If this port were available, then it would be group “dialout”. I’ll recommend using a different port, but if not, then you can disable nvgetty.service:

sudo systemctl stop nvgetty.service
sudo systemctl disable nvgetty.service

One issue with the above is that serial console still runs in the bootloader. Any activity on this port from your side during boot will cause the bootloader to halt and wait for commands. If you have no serial device connected until after boot passes the bootloader, then it wouldn’t be a problem.

When the device is not used by other processes (in this case, nvgetty), the group ownership would revert to “dialout”. This is normal behavior. One would put their regular user in group dialout to allow that user to work without sudo. I’ll assume your user name is “ubuntu”, in which case one could add “ubuntu” to group “dialout” like this:
sudo usermod -aG dialout ubuntu

1 Like

Ah. That is odd. I thought this tty was bound to UART1 on the 40 pin header, but the serial console can rather be accessed via micro usb, right? Am I wrong to use port 8 and 10 on the 40 pin header? I would like to communicate via UART.

On the AGX you are correct about the micro-USB. I suspect you are also correct about the 40-pin header. However, you are guaranteed that if the “group” for the device special file is “tty”, then serial console is running on that logical port. I have not verified which port is supposed to route to which pin, but possibilities are (A) that device special file does not actually go to the 40-pin header, or (B) something has inappropriately run serial console on a header pin which was not intended as serial console.

One possibility (of several possibilities) for mislabel causing something to run on the pins which are not supposed to be serial console would be a device tree entry which is incorrect. Possibly the tree or extlinux.conf might pass on the wrong kernel command line to cause this (see “cat /proc/cmdline” to see your kernel command line). Possibly a udev rule is doing this.

Incidentally, my AGX also has tty as group for “/dev/ttyTHS0”, so I think you can eliminate some sort of “mislabel”. Likely it is a confusion of which pin belongs with which device special file.

Someone else should be able to verify that the ttyTHS0 you are using goes to the micro-USB port versus going to the 40-pin header.

For what it’s worth, I verified that I can access the serial console using the micro usb connection. Meanwhile, looks like the console should live in ttyTCU0:

$ cat /proc/cmdline 
console=ttyTCU0,115200 video=tegrafb earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt rootfs.slot_suffix= usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues=0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1    quiet root=/dev/nvme0n1p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4

What gives? Can I fix this on my unit or does nvidia need to fix?

It is an interesting question. On my AGX I ran this command:
sudo systemctl stop nvgetty.service
…and yet the tty group ownership of “/dev/ttyTHS0” remained.

You are correct that the kernel command line names only “/dev/ttyTCU0” as a serial console, so parameters passed to the kernel did not cause serial console to take ownership of “/dev/ttyTHS0”. Something is not right with this.

I don’t see anything specifically causing this, but it might be related to odm-data (not sure). Would someone from NVIDIA be able to name what is causing group “tty” on “/dev/ttyTHS0”? Or why stopping “nvgetty.service” would leave both “ttyTHS0” and “/dev/ttyTCU0” with group “tty”?

Any update on this topic?

hello per.edwardsson,

don’t there’s J501, a Micro-USB connector provides access to the UART console, you can access the serial console of the developer kit from a terminal emulator on a computer connected to this micro-USB port.

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