UEFI garbled text, my current version is t26x_general UEFI firmware (version 38.2.1-gcid-42061081 built on 2025-09-10T19:13:20+00:00)（r38.2.1). According to the instructions at https://docs.nvidia.com/jetson/agx-thor-devkit/user-guide/latest/twa_headless_on_uefi-38-0-0.html, there shouldn’t be any issue, but it’s still garbled and I can’t enter the menu.
I tried changing the number of putty rows 244 and columns 60, but it didn’t work either.
Hi wpceswpces,
Please refer to the Tegra Combined UART guide and use the nv_tcu_demuxer tool to capture logs from CCPLEX: 0. Doing so should resolve the garbled message issue.
Hi,KevinFFF
Thanks for your reply. I just tried using nv_tcu_demuxer to demux the combined UART and using Minicom to retrieve information, and there is no garbled text. However, there is a very strange issue. Our custom carrier board exposes UART5 (/dev/ttyAMA5), and I found that when I short-circuit the RX and TX of UART5 externally and power on the system, for some reason, data comes in and interrupts the boot process, entering the UEFI menu. Moreover, there is continuous signal transmission in the menu. If I disconnect the short-circuit between UART5 TX and RX and power on , this issue doesn’t happen, and the system boots directly. I’m not sure where this data, causing the system to enter UEFI and continuously sending signals, is coming from — is it from the hardware link or something internal in the driver? In my opinion, the debug UART and UART5 should be independent of each other. Why does it seem like they are related?Can you help analyze this?
Yes, it is the expected result that we suggest using demuxer tool for serial console on Thor as there’re mutiple firmwares outputing logs at the same time during boot up.
It may be the secondary debug UART so that you gets the unexpected data output.
Please simply use the scope to check if there’s the log output.
Hi,KevinFFF
But I think it’s unlikely that there will always be a signal every time, which could simulate sending an ESC. Could it be that there’s a bug in the UEFI here?
The input from serial console may interrupt the boot and enter into UEFI menu.
That’s why we don’t suggest connecting the serial device on debug UART port.
I’ve checked the video you shared in previous reply. It seems there’re the inputs on that UART interface.
Hi,KevinFFF
I just don’t understand. Why does interrupting the UEFI to enter the menu require a very specific ESC key, and how is it possible for a signal to precisely simulate the ESC key? We’ve encountered a similar issue on the Orin as well. However, on Orin, the RX pin on the serial port doesn’t have a pull-up resistor. I’m not sure if this issue is related to the hardware, but what I don’t understand the most is why exactly the ESC key is simulated.
I don’t know the contents on your UART bus which may cause the same behavior of ESC key.
You may use logic analyzer to check the exact data.
As my understanding, the debug UART RX is not expected to receive the data during boot if you don’t want to enter into UEFI menu or interrupt the boot.
For the original garbled message issue, it has been resolved through using demuxer tool.
Is your current issue about the data on the serial interface which causes booting interrupted?
Do you have the requirement to enter into UEFI menu in your case?
Hi,KevinFFF
We don’t have the need to enter the menu, but it gets interrupted for some unknown reason. On the Orin, there is no hardware pull-up on the RX, and we found that there’s a probability of interruption occurring. We are not sure if it’s related to the lack of pull-up, and we are still verifying this. On Thor, we added pull-up hardware, but I found that if other UART loops are connected externally, it will inevitably cause an interruption.
Maybe you can refer to the following thread to remove that function in UEFI to prevent the boot interrupted due to any serial input as you don’t need to enter into UEFI menu.
Close or hide UEFI menu - #3 by KevinFFF
