This is output from Jetson Nano
ion@ion-desktop:/proc/device-tree$ egrep -R -H -a -i 'serial@'
__symbols__/uartd:/serial@70006300
__symbols__/uartb:/serial@70006040
__symbols__/uartc:/serial@70006200
__symbols__/uarta:/serial@70006000
aliases/serial3:/serial@70006300
aliases/serial1:/serial@70006040
aliases/serial2:/serial@70006200
aliases/serial0:/serial@70006000
chosen/stdout-path:/serial@70006000
log_dmesg.txt attached
log_dmesg.txt (68.0 KB)
Just writing some notes as I look…
“ttyS0” has address 70006000 (0x70006000").
“ttyTHS1” has address 70006040 (“0x70006040”).
There has been no mislabel of the same device (same address) with two different device special serial numbers. Meaning udev did as it should and gave the next UART name “tty...1” rather than giving a single piece of hardware names “tty...0” and simultaneously something like “tty...1”.
Some interesting dmesg log lines:
# egrep -i '(ttyTHS1|ttyS0|console)' log_dmesg.txt
[ 0.000000] bootconsole [uart8250] enabled
[ 0.000000] Kernel command line: 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=1125 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 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0
[ 0.001673] Console: colour dummy device 80x25
[ 0.001685] console [tty0] enabled
[ 0.001691] bootconsole [uart8250] disabled
[ 0.393338] console [pstore-1] enabled
[ 1.125434] console [ttyS0] disabled
[ 1.125506] 70006000.serial: ttyS0 at MMIO 0x70006000 (irq = 63, base_baud = 25500000) is a Tegra
[ 1.125609] console [ttyS0] enabled
[ 1.126615] 70006040.serial: ttyTHS1 at MMIO 0x70006040 (irq = 64, base_baud = 0) is a TEGRA_UART
[ 1.129969] Console: switching to colour frame buffer device 240x67
bootconsole” for uart8250 is from the bootloader, and uses the legacy driver (thus, once in Linux, it is “/dev/ttyS0”).ttyS0 to be the serial console.Then, for some unknown reason, I see ttyS0 console disabled, followed by enabling it again, but naming is still valid as ttyS0 remains as an alias to address “70006000”. “ttyTHS1” has not yet been mentioned, so everything is normal to this point.
After the above ttyTHS1 is assigned its name and bound to address 0x70006040, but this is just UART setup and does not yet associate this with serial console. In fact the dmesg log never tells us that ttyTHS1 is ever assigned as a console.
So far as the operating system goes during boot, using its configuration files, there is no error. It is like some other software adds ttyTHS1 to serial console without the operating system itself ever doing this. If there have been no changes by you, then you have found a bug. A possible exception to this though is that if console did actually switch, and it isn’t just a mislabel of the device, then a log line would have been lost during the changeover, and the old device might have stopped logging.
There is a lot going on in the thread, and I might have asked before, but wanted to ask (or ask again) the following:
/dev/ttyS0” or “/dev/ttyTHS1” as the related UART, which one will work as a serial console? You can use “sudo” if needed. Errors trying to open either device (with sudo) would be of interest.Is there any modification which might have been made which is related to any UART?
No. Just flashed the downloaded MicroSD card image into a MicroSD card and boots up from the SD card.
/dev/ttyS0 ” or “ /dev/ttyTHS1 ” as the related UART, which one will work as a serial console? You can use “ sudo ” if needed. Errors trying to open either device (with sudo ) would be of interest.I Can’t open /dev/ttyS0 and /dev/ttyTHS1 with putty as normal user. look at the screen captued below:
This is the error message from terminal
ion@ion-desktop:~$ putty
(putty:9139): Gtk-CRITICAL **: 15:50:30.869: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
I can open both /dev/ttyS0 and /dev/ttyTHS1 with putty as root user at the same time from the different terminal. No error message from the Putty
In the case of opening either ttyS0 or ttyTHS1 with sudo, do both function as a console? Meaning that not only is connection allowed, but that it functions as a console?
Did you create an SD card image yourself with JetPack/SDK Manager? Did you also flash the Jetson with the same release version which created the SD card? I’m looking to see if the modules QSPI memory (used in boot) is working with a rootfs partition (the SD card content) of a compatible release (strange things could happen if you mix QSPI from one release with an SD card rootfs of another release).
I did not create my own SD card image and also not use JetPack/SDK manager to create / install the SD card.
I just follow the steps below to flash the SD card
How can I test this?
My dear friend, the file “/etc/systemd/nvgetty.sh” contains " setsid /sbin/getty -L 115200 ttyTHS1" . Comment out the code.
Thanks. Your solution works.
That makes sense, glad you saw that. Makes me wonder why that line existed since it probably should have never been there.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
