Trouble using UART with ttyGS0

[u1076332]

Hi all,

I am attempting to follow along with this tutorial: https://jetsonhacks.com/2019/10/10/jetson-nano-uart/

When I first connect the tty to USB to my pc and run PuTTY, I am able to log in to the Jetson.
I close the PuTTY connection, stop and disable nvgetty in the Jetson terminal.

When I run the uart demo and open a new PuTTY connection, ttyGS0 reconnects, and I get a series of strange character appearing in the Jetson terminal. I’m assuming I’m getting a mix of the two connections?

Is there another step to disabling the UART ports for the purpose of Serial Console connection?

Cheers,
Scott

[linuxdev]

What follows is for the running system. This does not include what goes on during boot.

To temporarily stop serial console:
sudo systemctl stop nvgetty.service

To then set serial console to not run:
sudo systemctl disable nvgetty.service

To re-enable:
sudo systemctl enable nvgetty.service

[u1076332]

Hi Linuxdev,

thanks for that. I’ve given those commands a try but the problem is still there. I ran the stop and disable nvgetty.service commands, and relaunched the UART demo. The ttyGS0 still seems to be online.

When I run the demo, I initially get a blank screen on the Putty window, but after entering any character inputs, a prompt for a password appears, a timeout message appears, then the login to the Jetson reappears.

[linuxdev]

During boot stages (which is before Linux runs) there is essentially a different operating system, and the only purpose of that first o/s is to overwrite itself with Linux. During that time I would not expect the nvgetty.service to have any effect, but your log is from when Linux itself is running, and so the serial console commands should be effective. Perhaps though there is something in the setup beyond that.

What do you see from:

• cat /proc/cmdline
• df -H -T
• lsblk -f

The above won’t change anything, but it might give a better idea about what is booting. Since you have a serial console login prompt, could you use your serial console program to log the entire boot? Basically, you would connect the serial console, start your program, and without having powered on the Jetson, then start logging in the serial console program. Then power on the Jetson and let it get to that prompt. You don’t need to keep logging after that (the point is to show what log lines show up prior to and right at the moment the Linux kernel loads).

Most of the reason for the above is that nvgetty.service disabling should work (I’m assuming you did not re-enable; if you did re-enable then skip that next time…the reason for mentioning re-enable was if you ever wanted to use serial console again, then that is how you would turn it back on).

[u1076332]

Outputs:

cat /proc/cmdline:

tegraid=21.1.2.0.0 ddr_die=4096M@2048M section=512M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 console=ttyS0,115200n8 debug_uartport=lsport,4 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff780000 core_edp_mv=1075 core_edp_ma=4000 gpt tegra_fbmem=0x800000@0x92ca9000 is_hdmi_initialised=1 earlycon=uart8250,mmio32,0x70006000 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 nv-auto-config quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 nv-auto-config

df -H -T

Filesystem Type Size Used Avail Use% Mounted on
/dev/mmcblk0p1 ext4 32G 18G 13G 59% /
none devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs tmpfs 2.1G 41k 2.1G 1% /dev/shm
tmpfs tmpfs 2.1G 23M 2.1G 2% /run
tmpfs tmpfs 5.3M 4.1k 5.3M 1% /run/lock
tmpfs tmpfs 2.1G 0 2.1G 0% /sys/fs/cgroup
tmpfs tmpfs 415M 144k 415M 1% /run/user/1000

lsblk -f

NAME FSTYPE LABEL UUID MOUNTPOINT
loop0 vfat L4T-README 1234-ABCD
mtdblock0
mmcblk0
└─mmcblk0p1 ext4 926cd5fe-2a7d-4f14-9f21-b7b8a7496bff /
zram0 [SWAP]
zram1 [SWAP]
zram2 [SWAP]
zram3 [SWAP]

I’m having some troubles connecting the serial monitor to record the boot series. So far I’ve only got this shaky photo of the screen just before the NVIDIA logo shows up.

[linuxdev]

Before saying more I want to describe something regarding the built in UARTs. This may not be the case for UARTs which go to the micro-OTG USB connector, but it does apply to UARTs on header pins.

The naming of a device special file for a UART initially depends on the driver, and this in turn depends on the chipset. A generic 16550A will have a driver that uses names like “ttyS0”. A USB UART from Microchip will have a name at the USB end of something like “ttyUSB0”. Jetson drivers for a 16550A which has DMA added will have a naming convention like “ttyTHS0”. It is possible that the udev system will rename that file or add other aliases.

On a Jetson the integrated UARTs are 16550A compatible (they can be a couple of other older compatibilities by changing firmware). In your “/proc/cmdline” you’ll see your kernel was (upon load) told to start a serial console on ttyS0 at speed 115200 baud, 8-bit, no parity (also no stop bit by default). This excerpt says to do this:
console=ttyS0,115200n8
(this isn’t the whole story, but it is the start in Linux)

What isn’t obvious is that one of the integrated UARTs can in fact have two different drivers. As an example, the driver which produces /dev/ttyTHS0 with DMA can be the same hardware that produces /dev/ttyS0, but that you shouldn’t use both simultaneously (you could alternate).

I would not expect ttyGS0 to also be ttyS0, but maybe I have a misunderstanding of physical UARTs that are present. All of the UARTs going to UART header pins have two possible names. Maybe the USB OTG port does too? The point is that if something is told to add a serial console to a UART you are using, then you’ll see that traffic even if you are using a different UART device special file (a different driver) when it is the same actual underlying hardware.

When one disables the nvgetty.service, then one is disabling all serial consoles so far as I know. Every related UART would stop being a serial console during time where Linux is loaded (prior to this in boot stages it is a different story…the boot software is its own bare metal operating system).

I am surprised that the stop and disable of nvgetty.service still results in serial console running.

The lsblk -f shows you don’t have any special partition mount setup. It’s just the eMMC. If it had been some other boot scheme, then it would have been possible for the setup to actually be on some other storage media followed by switching to a new media. This would cause some setup commands to not do as expected, but this is not the case in your setup.

The screenshot is not very useful. What would be really useful (oddly and poetically enough) is a full serial console boot log, but we’re trying to disable that. The part of the log which does show is unrelated to the issue (and for example, if you don’t have the imx219 sensor, then I’d expect the i2c to fail). Since this shows up as a console login, if you start a serial console program on another computer, and monitor that setup with settings of 115200 8N1, do you get a boot log? If you do, then log the entire sequence and post it here. It might say something I don’t see from the given information.

[u1076332]

Hi LinuxDev,

Thank you for all of your time and support so far with this. I truly appreciate it, and I’m really learning alot!

As of this morning, I have re-flashed the Jetson, new OS on a new SD card, ordering new cables.
If I can’t get it working after that, it’s either my host PC or a damaged board.

If I have any further luck with this I’ll check back in and report.

Kind regards,
Scott

[u1076332]

Hi LinuxDev,

I’ve had a bit of an adventure up to this point. It turns out that I was getting confused with the microSD connection to the board, and the UART_example script was reading traffic on that connection. After unplugging the microSD cable (that was also connected to my PC) the mingled data connection has stopped, but so has all output from the UART pins.

so, after that revelation, I’ve wiped and reimaged the Nano - new SD card, new image loaded onto it with etcher. New install and user setup.
New TTL to USB cable.
Ensured the only connection out of the Nano is the UART cable.
No information is being received by PuTTy on the PC.
I’ve borrowed a different PC with tested with PuTTY on it - no output from the Nano.

With no other connections to muddy the water, I can’t seem to get any connectivity through the UART pins at all.

[linuxdev]

Is this specifically one of a Jetson Nano developer kit from NVIDIA? Or is this some third party carrier board? On a dev kit the SD card slot is on the back of the module itself, whereas any third party carrier board would place the SD card slot on the carrier board (not on the module). There are also a couple of models of dev kit (early days versus not as early “revision”). Here is a Jetson Hacks URL which is quite helpful for dev kits:
https://jetsonhacks.com/2019/04/19/jetson-nano-serial-console/

FYI, if you have nvgetty.service disabled, then this would account for no output even if the serial console is otherwise set up correctly. If it is set up correctly, and you have no serial console output, then you can enable as shown in my earlier reply.

The non-serial console UARTs are usually used with a device name (at the Jetson end) of /dev/ttyTHS# or /dev/ttyS# (both can be to the same UART, it just changes name depending on driver). The ttyGS0 tells me serial console dedicated UART on a unit which has serial console to the micro-OTG port instead of individual pins on the carrier board.

I am not familiar with the particular tutorial, and so I can’t say what UART it is looking for, e.g., serial console versus the virtual wired ethernet over the micro-OTG USB port. If you want serial console, then the answer is different than if it wants a network connection.

[u1076332]

As far as I’m aware I’ve purchased a legitimate NVIDIA Jetson Nano Developer kit. The SD card slot is on the back. Thanks for that link, I’ll test that out shortly and see.

Enabling or disabling nvgetty does not change any of the test results.

The ttyGS0 error I believe was related to my use of the micro-USB. Since unplugging that cable, I believe that only ttyTHS# should be being used.

More broadly - with how straight forward the tutorial makes this setup out to be and given I’ve wiped the entire OS on the Jetson nano has been and re-installed, and replaced everything from the cabling to the receiving PC, is there a feasible reason for this error apart from a faulty board?

[linuxdev]

For “normal” use (not serial console, nor for any special use case) you could use either a “/dev/ttyTHS#” or a “/dev/ttyS#”. Both refer to the same UART, but use different drivers. Normally you would use the ttyTHS# if in Linux; boot stage code prior to Linux running would normally use the ttyS# driver.

In every case where a UART is not used by the Jetson itself (e.g., for serial console), then the “group” of ownership will be “dialout”. Check this:
ls -l /dev/ttyS* /dev/ttyTHS*
(keep in mind that the numbers are not necessarily the same in the # part; numbering is dependent upon order of driver load, and is not determined by the particular hardware)

I’ve not see anyone using the ttyGS0, but maybe it is used for something. I would double check to see if that is correct. I suspect this is why it fails.

Serial ports rarely ever fail. They are quite reliable. They can be picky at higher speeds, and they will “appear” to fail if one side of the connection is set differently than the other side. Still, it is possible that a UART failure would be from a hardware failure.

I can’t say anything about the particular tutorial or project which leads you to using ttyGS0. Can anyone from NVIDIA comment on when a Nano would use ttyGS0?