Hi
I am trying to use serial using ttyS0 and the j44 Tx/Rx.
The problem is that i lose permission to read from ttyS0 constantly.
The fix right now is to constantly use sudo chmod 666 ttyS0 or sudo chown to use the serial-connection.
System: Ubuntu 18.04
I am trying to connect the jetson with a Raspberry Pi both running a Python-script.
ls -l /dev:
crw–w---- 1 root tty 4, 64 okt. 12 18:16 ttyS0
can anyone help?
read in some forums that the problem might be udev, but i cant find any 91-permissions.rule
The easiest solution on most Debian based systems, including Ubuntu on the Jetson products, is to add your user account to the ‘dialout’ group.
If the user account you are using is nvidia then execute:
sudo adduser nvidia dialout
This will add nvidia to the dialout group. The change will take effect the next time the nvidia user will be member of the dialout group and have access to /dev/ttyS0.
i have already tried that, i am a member of dialout
jet@jet-desktop:/sbin$ sudo adduser jet dialout
The user `jet' is already a member of `dialout'.
But as you can see when i try ls -l /dev i only have permissions to write. meaning that sending data from the Jetson to the PI works smoothly, but when i try the other way i cant
ls -l /dev:
crw--w---- 1 root tty 4, 64 okt. 12 18:16 ttyS0
Have you modified the udev rules? Normally ttyS0 is in the dialout group.
You could try adding the user to the tty group.
Hi
Where can i modify the udev-rules so that ttyS0 is attached to the dialout-group?
But still, groups only have “write”-permission
i am also a member of tty
That’s very strange. Can you re-flash the standard Nvidia image?
FYI, the device will only become a member of tty if it is used for serial console or other login daemon is attached to the tty. Permissions won’t help you until the other process does not control the ttyS0. I don’t remember the details, but probably nvgetty is in need of stop/cancel to revert back to being just a terminal.
When dialout owns the port you will find group dialout has both read and write access; tty is set to write only and thus even if you were a member of ttyS0 group “tty” you’d never be able to read.
If interested in udev (which won’t matter if you simply stop nvgetty…I forget the actual service to stop, hopefully someone else knows), then modifications to the local system occur somewhere in “/etc/udev/”. Files there might be edited copies of the “/lib/udev/rules.d/” content, or a symbolic link directly to one of those files might exist in the “/etc/udev/” content (sym links are good for naming a standard behavior when there is a choice among various behaviors, e.g., text-only initial boot mode versus GUI boot mood both have udev files, but only one is picked…usually via a sym link). People modifying existing behavior simply copy one of the original files into etc and edit…deleting the edited file reverts back to original behavior.
1 Like
Hello
Thank you for your feedback.
i tried to disable nvgetty.service, but not sure that was the way you proposed(it did not work).
What worked for me was to move the file ttyS0 over to ttyS1 since the thing that continuously changes the permissions only does it for ttyS0
So:
sudo mv /dev/ttyS0 /dev/ttyS1
sudo chmod 666 ttyS1
worked for me.
I’m surprised that worked. In the future you may find unexpected bugs. The file is basically just a pointer to the driver itself, and the driver may change things which the file itself has no control over. Moving the file doesn’t really change the driver.
Have the same problem. Any solutions?
If you see my last comment, my fix was to move the file to ttyS1.
I do not believe that it’s the right approach to solving the problem, but i have still to experience any issues with it.
You might try this to avoid nvgetty taking ownership if it is related to serial console (otherwise it probably won’t help):
sudo systemctl stop nvgetty.service
sudo systemctl disable nvgetty.service
The reverse if you wanted to enable it again:
sudo systemctl enable nvgetty.service
sudo systemctl start nvgetty.service