My Jetson Xavier NX’s ttyTHS0 serial port is connected to the flight controller of a drone. When I enter the reboot command in the command line, the Jetson enters the BIOS interface and moves the selected line (as if a keyboard were operating it). I seek assistance in resolving this issue, suspecting that the Jetson is treating the flight controller’s serial port as a keyboard input. This issue occurs on JetPack 5.1.1 and 5.1.3, but strangely, it does not occur on JetPack 4.6.
Hi 443683123,
Are you using the devkit or custom board for Xavier NX?
Do you mean that the data coming from ttyTHS0 interrupt the boot and enter into UEFI menu during boot up?
Please share the /boot/extlinux/extlinux.conf from your board for further check.
Hi KevinFFF,
I use custom board for Xavier NX.
Yes, I think so.
I didn’t modify the text from extlinux.conf, There are context:
TIMEOUT 30
DEFAULT primary
MENU TITLE L4T boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
FDT /boot/dtb/kernel_tegra194-p3668-0001-p3509-0000.dtb
INITRD /boot/initrd
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=efifb:off nospectre_bhb nv-auto-config
# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
# sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot
# LABEL backup
# MENU LABEL backup kernel
# LINUX /boot/Image.backup
# FDT /boot/dtb/kernel_tegra194-p3668-0001-p3509-0000.dtb
# INITRD /boot/initrd
# APPEND ${cbootargs}
Note that if you use the serial port which is assigned as serial console, then entering activity (sending to the Jetson) is the same as randomly typing text into a console. You would also be getting text back (receiving from the Jetson) that is the console output. If that is the case, then keystroke activity (anything that has any activity at all transmitted to the Jetson) is the same as intentionally interrupting boot via a keystroke.
However, /dev/ttyTCU0 is on a different micro-USB connector. When fully booted, what is the output of this:
ls -l /dev/ttyTHS*
ls -l /dev/ttyTCU0
When the associated group is dialout, then that port is available. When the associated group is tty, then that port is a console. The above ls commands will tell you which ports are restricted to console operations. If your port is dialout, then it isn’t stopping boot, but something touching the tty port might be interfering with boot.
crw--w---- 1 root tty 238, 0 May 8 21:10 /dev/ttyTHS0
crw-rw---- 1 root dialout 238, 1 May 8 21:16 /dev/ttyTHS1
crw-rw---- 1 root dialout 238, 4 May 8 21:10 /dev/ttyTHS4
crw--w---- 1 root tty 237, 0 May 8 21:10 /dev/ttyTCU0
I’m currently using the THS1 port and the THS0 port, both of which are causing the system to automatically enter the BIOS.
These are serial consoles and not available for other purposes:
crw--w---- 1 root tty 238, 0 May 8 21:10 /dev/ttyTHS0crw--w---- 1 root tty 237, 0 May 8 21:10 /dev/ttyTCU0
The others are available. I would expect that if /dev/ttyTCU0 exists, then it would be a serial console. At times I would expect /dev/ttyTHS0 to be either a serial console or some other function. I would not expect both ttyTCU0 and ttyTHS0 to both be serial console.
This part of your APPEND line of extlinux.conf is why (at least for part of boot) ttyTHS0 is a serial console (but this isn’t the whole story):
console=ttyTCU0,115200n8
Keep in mind that the boot chain is its own operating system on bare metal. When the Linux kernel loads it overwrites the boot chain and inherits the environment, and this officially is running Linux and is no longer running the boot chain. Configuration to enable or disable can be different in either stage. Because it is during boot stage that boot is halting we don’t really care about the Linux stage (at least at first). Once in Linux there is also the systemd service, and you would probably care due to garbage in and out from attempts to log in to the console not knowing this is what your application on serial is doing, but once in Linux, there is no more halting of boot via that device.
You do not need to remove the ttyTCU0 from serial console. However, I am confused how ttyTHS0 became a serial console in boot stages. You will need to disable serial console over ttyTHS0 during both boot and once in Linux if you want to use this for your own purposes.
Could you provide more specific instructions? I’m still quite confused about how to proceed in order to resolve this issue.
This isn’t normal, so I couldn’t answer. Was there any modification of the flash software, or the boot software? It is expected that ttyTCU0 is owned by group tty, but the only way that ttyTHS0 became group tty is if something put a console on that UART. Perhaps if you had the wrong device tree, e.g., if you used the NVIDIA flash software on a third party carrier board, this might happen. You could always back up the eMMC or SD card, and flash again, but I’m puzzled that the wrong UART is serial console in addition to the correct UART.
1 Like
Please try to remove console=tty0 in APPEND of your extlinux.conf.
When I followed your method to remove ‘console=tty0’, I tried the ‘reboot’ command, but still couldn’t start normally (at this time, my flight control device is connected to the THS0 port).
Could you also try to remove nvgetty.service and check if it could help for your case?
$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service
$ sudo rm /etc/systemd/system/nvgetty.service
If no, you can refer to the following thread to disable the feature to prevent it entering into UEFI menu.
Close or hide UEFI menu - #3 by KevinFFF
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.