ttyS0 group doesn't have read permission

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

I have a TX2 running L4T 28.1 in a carrier board and need to use the serial port. The serial port on the carrier board maps to ttyS0 which by default is owned by root and belongs to group tty. I’ve added user ubuntu to group tty (which is what I log in as) however by default the group doesn’t have read access to ttyS0. sudo chmod g+r /dev/ttyS0 fixes it, but this doesn’t persist through a reboot. I’ve tried creating various udev rules (99-z_setup.rules):

KERNEL=="ttyS0", NAME="ttyS0", SYMLINK+="my_tty", GROUP:="tty", MODE:="0660", OWNER:="ubuntu"

KERNEL=="ttyS0", NAME="ttyS0", SYMLINK+="my_tty", GROUP:="tty", MODE:="0660"

KERNEL=="ttyS0", NAME="ttyS0", SYMLINK+="my_tty", GROUP="tty", MODE="0660"

these result in:

lrwxrwxrwx  1 root root           5 Aug  1 13:34 my_tty -> ttyS0
crw--w----  1 root tty       4,  64 Aug  1 13:34 ttyS0

so I still can’t access it. I also tried

KERNEL=="ttyS0", ACTION=="add", PROGRAM="/usr/bin/sudo /home/ubuntu/bin/setup_tty.sh"

with setup_tty.sh containing

#!/bin/bash

chmod g+r /dev/ttyS0
echo "setup_tty ran" >> /home/ubuntu/bin/tty.log

It echos to the tty.log file so I know the script runs, but the permissions are still

crw--w----  1 root tty       4,  64 Aug  1 13:44 ttyS0

It’s like the group / owner / mode settings are being ignored or being overwritten.

Any ideas?
Thanks,
Jason

2

ttyS0 is already in use as a serial console. This means another user is automatically using this before the Jetson even finishes booting (user “nvidia”). You could try to instead use the J17 serial port (ttyTHS2…both S0 and THS2 use default settings 115200 8N1 with no flow control).

FYI, there is a combination of things setting up ttyS0 at stages before Linux ever runs since serial console starts before even U-Boot. Some of that goes away once the Linux kernel is running if you edit the kernel command line, but any stray keystroke or data on ttyS0 prior to that could still cause boot to halt. It would be far simpler to just use ttyTHS2.

3

That makes sense. I tried ttyTH2 and it works great. Thanks!

4

I am also getting this problem. I am trying to use the S0 serial port as it is compatible with raspberry Pi HAT modules (power and IO locations). Is there a way to have the kernel stop using it after boot? I have confirmed that the board I am using does not interfere with boot when attached and only need to access that serial port after the system is fully booted (I can handle delays of up to a minute or two). It looks like no-one is currently using the port (

lsof /dev/tty0

returns nothing).

I know that the preferred solution would be to make my own boards that have connectors for the J17 UART, but I am looking to avoid that for now if at all possible.

5

Serial console is what I would consider “important backup” in embedded. However, if you remove the right part of the kernel boot argument, then this tty will stop being used for console and messages once Linux starts. On the other hand, if this port sees any activity at all during boot within the U-Boot stage, then your system will halt. You’d need to have any hardware removed from this port until after boot completes.

For more recent releases the kernel command line boot arguments are in the device tree, and the device tree is flashed to a partition after being signed. Thus simple steps of updating a file and copying it in no longer apply.

Within the device tree look for “chosen”. This will have a node within it, “bootargs”. A kernel accepts two consoles as arguments…you’d be removing the arguments related to serial console. Those arguments look like:

console=ttyS0,115200n8

Eliminate those from your device tree, and then flash the new device tree. Serial console should then be removed after U-Boot is gone (you would have to modify U-Boot to get rid of it there).

J17 is probably looking nicer :P