Read data from UART without superuser permissions

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

Hi,

I am trying to read data send by another device through UART,
Looking through the spreadsheet I found online, I connected RX to pin 10 and TX to pin 8 on the 40 pin header extension.
Then I opened port on /dev/ttyTHS0 and I could read the data sent by the device. But the problem I am facing now is that I cannot read data without granting su permission to my application. How can I avoid this ? I have had similar issue when using USB device to read the data, to fix it i just added my user to dialout group but that doesnt seem to work with THS0.
Please advice! Thanks

~$ ls -al /dev/ttyT*
crw--w---- 1 root tty       4, 143 Mar 30 10:24 /dev/ttyTCU0
crw--w---- 1 root tty     238,   0 Mar 30 10:24 /dev/ttyTHS0
crw-rw---- 1 root dialout 238,   1 Mar 30 10:24 /dev/ttyTHS1
crw-rw---- 1 root dialout 238,   4 Mar 30 10:24 /dev/ttyTHS4
2

Create the file /etc/udev/rules.d/00-THS0.rules with the following content:

KERNEL=="ttyTHS0" OWNER="root" GROUP="dialout" MODE="0660"

Then issue the command udevadm trigger.
Now anyone with the “dialout” group can read/write /dev/ttyTHS0.

1 Like
3

As an extension to what @gtj mentions: A regular user is normally a member of group “tty”, but is not normally a member of group “dialout”. If you want to see who is a member of those groups:
egrep '(tty|dialout)' /etc/group

Anyone working on development probably should be added to group “dialout”. If your user name is “ubuntu”, then this would add group “dialout” as a supplemental group to user “ubuntu”:
sudo usermod -aG dialout ubuntu
(you’d then see ubuntu in group dialout when examining /etc/group…a similar useful group to add is “gpio”)

4

It doesnt seemto be persistant, after reboot it doesnt work anymore, had to run sudo udevadm trigger again, any thoughts why this happened ?

5

What does sudo systemctl status systemd-udevd show?

6

@gtj here’s the output

systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor preset: enabled)
   Active: active (running) since Tue 2021-03-30 23:54:40 +04; 51s ago
     Docs: man:systemd-udevd.service(8)
           man:udev(7)
 Main PID: 2535 (systemd-udevd)
   Status: "Processing with 20 children at max"
    Tasks: 1
   CGroup: /system.slice/systemd-udevd.service
           └─2535 /lib/systemd/systemd-udevd

Mar 30 23:54:41 defuser-jetson systemd-udevd[3192]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 30 23:54:41 defuser-jetson systemd-udevd[3192]: Could not generate persistent MAC address for dummy0: No such file or directory
Mar 30 23:54:41 defuser-jetson systemd-udevd[4207]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 30 23:54:41 defuser-jetson systemd-udevd[3225]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 30 23:54:41 defuser-jetson mtp-probe[4414]: checking bus 2, device 3: "/sys/devices/3610000.xhci/usb2/2-3/2-3.3"
Mar 30 23:54:41 defuser-jetson mtp-probe[4414]: bus: 2, device: 3 was not an MTP device
Mar 30 23:54:43 defuser-jetson systemd-udevd[5498]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 30 23:54:43 defuser-jetson systemd-udevd[5498]: Could not generate persistent MAC address for l4tbr0: No such file or directory
Mar 30 23:54:43 defuser-jetson systemd-udevd[5508]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 30 23:54:43 defuser-jetson systemd-udevd[5507]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
7

Oh duh… rename the file to 99-THS0.rules so it gets executed after everything else. Sorry.

1 Like
8

weird but still no luck, I have renamed the file and re issued the command, still after restart I get “Permission denied”

9

OK but what does ls -Al /dev/ttyTHS0 look like after the reboot?

10

absolutely the same as above

12

That’s pretty weird. It does work for me but maybe you have another rules file interfering.
Paste the results of the following command…

$ sudo udevadm test $(udevadm info -q path -n /dev/ttyTHS0)

Also try renaming the file again to 99-zzTHS0.rules so that it absolutely comes last.

13

I just found another thread where prior to these changes, the following command should also be issued to make it work.

sudo systemctl disable nvgetty.service

I confirm the issue is gone, now after reboot I can properly read data from UART without supplying superuser permissions!

Thanks for the effort @gtj

14

Hi streakflash,
I’m also interested to communicate with UART without using sudo.
Did you do something else to make it work ? After entering this commands and rebooting i get permission denied while trying UART.
sudo systemctl disable nvgetty.service

15

@Bazziil run this set of commands

sudo usermod -a -G dialout $USER
echo -e 'KERNEL=="ttyTHS0" OWNER="root" GROUP="dialout" MODE="0660"' | sudo tee /etc/udev/rules.d/99-zTHS0.rules
sudo systemctl stop nvgetty.service
sudo systemctl disable nvgetty.service
sudo udevadm trigger
reboot
4 Likes
16

@streakflash thanks it works !

17

Ha! I forgot I did that a long time ago. Glad you got it sorted.