Jason nano 2GB, Jetson pack 4.6.1
I successfully configured ttyTHS1 with the help from linuxdev top Contributor and JerryChang
But when I try to config the other one: ttyS0, (I try check group, and it is “tty” group) the problem is : can transfer data only but can not receive the data. Please help
Jason nano 2GB, Jetson pack 4.6.1
tty means console is already using that port, so you cannot use this until serial console is disabled or moved to a different port. To disable:
sudo stop nvgetty.service sudo disable nvgetty.service
You should also beware that when you look at a serial device with naming convention “
ttyS#” that this is a legacy driver (which early boot supports), and that the convention “
ttyTHS#” is for the newer “Tegra High Speed” driver. These are two separate drivers which can operate on the same UART, but you should not use both simultaneously. Be careful to not consider
ttyS0 and possibly one of the
ttyTHS files as two separate UARTs. I think
ttyTHS1 is a separate UART compared to
ttyS0, but there can be exceptions.
Thanks linuxdev for quick response.
Since Jason Nano 2GB has 2 sets of pins headers at which provides the serial communication:
40-Pin Header J6
12-Pin Header J12
I try to use both headers for 2 seperate communications. One set is for ttyTHS1 and other for ttyS0. The ttyTHS1 is successful one. For ttyS0, I tried as your suggestions but it still does not work: ttyS0 allow sending out data only, NOT allow receiving data.
First verify that the group of
ttyS0 is “
dialout”. Once that is done, can you try a serial loopback test? What you would do is wire the
ttyS0 TX to RX, and optionally also CTS to RTS, then point a serial terminal program at
ttyS0. Typing in text should result in echo of the text to the terminal.
I made the change in 99-tegra-device.rules : KERNEL==“ttyS0” OWNER=“root” GROUP=“dialout” MODE=“0666”
And verify that group of ttyS0 is “dialout”. Then I did a serial loopback test as you suggested (wire the
ttyS0 TX to RX, then point a serial terminal program at ttyS0) but when typing in text, it did NOT result in echo of the text to the terminal.
Noted that the original GROUP of ttyS0 is “tty”
Please help. Thanks linuxdev
I just search around the FORUM, and see this interested one from you:
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:
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).
And my other question is that: HOW DO I FLASH THE NEW DEVICE TREE (my model is Jetson Nano 2 GB)
Just to emphasize, it isn’t changing group to
console which stops serial console from running. Group
tty is a side-effect, and changing it to group
dialout without stopping the console service will just break console and not stop it.
There are two independent locations where console will run:
- In the bootloader stages before Linux;
- In Linux itself.
Those two locations are independent. If you are not sending traffic to the UART during boot stages (prior to reaching Linux), then there is no need to change this.
Depending on release and setup it may be that it is enough to just follow the mentioned removal of the “
console=...” listed above for both. However, before you do this, I recommend removing the changes you made to set group to “
dialout”, and instead using
systemd to disable serial console within Linux. It is reasonable to remove the noted serial console argument in
extlinux.conf, but perhaps is unnecessary if you disable via:
sudo systemctl stop nvgetty.service
sudo systemctl disable nvgetty.service.
Once those two steps are taken the device special file should self-revert to group
dialout instead of group
console. This truly disables serial console rather than just breaking permissions. Does that help?
I tried all your suggestions, but this time it can receive less than 10 characters and then the “console” take over the ttyS0 and it stop receiving any character. Here 's my set up: Nano2GB connecting to PC via serial. The application on nano (using ttyS0) will send out 3 characters and wait to receive the data from PC. When I mentioned “console take over ttyS0”, it means that after the nano receive 5 characters then the nano sending out streaming of data … as the version of ubuntu, powerup info, that’s why I think the “console” took over the ttyS0. The “console” and the application used ttyS0 at the same time and cause traffic. So my questions: (1) How can I remove running of console from “bootloader”; (2) If it relates to device tree, I look at the directory /boot/dtb in which has file
Should we modify the file?
Thanks so much
Yes, typically console disable is just in Linux, and does not disable in boot stages (and in boot stages stray characters can cause issues during boot). In file “
/boot/extlinux/extlinux.conf”, do you see something similar to (the
ttyTCU0 might differ, someone else already mentioned this, but there is a twist in the story I’ll explain below regarding device tree):
If so, copy the original somewhere for reference, and then remove this from the file. Try again.
Once actually booted to Linux, verify that the group of “
ls -l /dev/ttyS0” is “
dialout”, and not “
Typically, if earlier boot stages get a stray character at the wrong moment, then the boot will halt rather than continuing. If boot actually runs Linux, then you know a stray serial console character halting was not an issue.
Also, sometimes device tree can add options not expected. What do you see from:
(this could reintroduce the above phrase I had you remove from
Which serial console application are you using for cases where you might just be testing? Or is this data entirely from a different means, e.g.,
echo or a program?
Btw, you are correct that if two programs both try to use the serial UART, then the behavior might be just what it is supposed to be doing. Also beware that there is a single UART behind both the “
ttyS#” naming convention (of a given “
#”) and the “
ttyTHS#” naming convention. The naming is due to different drivers on the same UART. If you were to use both the
ttyS# and the same UART via the
ttyTHS#, then there would be an undefined conflict. Just beware that each
ttyTHS# entry is not equivalent to different UARTs (they can be, but naming convention alone is not a way to verify a specific UART is unique).
In the case of removing any kind of serial console entry see:
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.