How to obtain UART logs on Jetson Nano production modules, over UART 2


We are using Jetson Nano production modules on our custom carrier boards. The issue stated here: still exists. Sorry for the delay in following up.

We are using Jetpack 4.2.1 as some of our drivers are according to that version, and we cannot upgrade anytime soon. Also, at the moment we are only able to bring out the UART2 port (because of the PCB design), i.e., connect only that port to the TTL-to-USB converter. And we do not have an HDMI port, so we cannot view logs on the monitor, so only via host system.

So basically normally our custom carrier boards would not have a serial communication capability, this cable is soldered just to investigate the issue mentioned in the link above.

We are able to see the console, after boot, over UART, on the host PC, where a tegra-ubuntu login is prompted, but no serial logs before/during booting. Enabling/disabling the nvgetty service does not help with obtaining the logs.

What we tried: modifying the p3448-0000.conf.common file, by changing the line:

CMDLINE_ADD="console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0";


CMDLINE_ADD="console=ttyTHS1,115200n8 console=tty0 fbcon=map:0 net.ifnames=0";

but it did not help. We are particularly interested in fetching the preboot logs, which we cannot find under dmesg.

To summarize: We think that UART logs are available over UART0 for our current configuration. But we want them over UART2. Is it possible?

We referred to the documentation:, but couldn’t figure it out.

hello jetson_user,

please access Jetson Nano Product Design Guide for [Figure 11-5. Jetson Nano UART Connections]
it’s by default using pin-203/205 for sending UART logs, and we’re able to see bootloader logs via this port on DevKits.

did you mean you would like to switch the debug port to pin-236/238?

Hi JerryChang,

Thanks for the reply. I’ll check the layout again on our side. Meanwhile, could you let us know how to ensure that UART logs (including preboot logs) are directed on UART2? Like via some source file in the kernel source code? We were just wondering if in our case they are directed to UART0, because we have the TTL to USB cable soldered to UART2, but we only see the tegra-ubuntu login prompt. There should be serial (UART) logs output continuously to the terminal, right?

hello jetson_user,

please refer to Jetson Nano Boot Flow, you should see below four paragraph during boot-up.
for example,

[0000.250] [L4T TegraBoot] (version 00.00.2018.01-l4t-de525542)
[0000.256] Processing in cold boot mode Bootloader 2
[0000.260] A02 Bootrom Patch rev = 1023
[0000.264] Power-up reason: pmc por
[0000.267] No Battery Present
[0000.270] pmic max77620 reset reason
[0000.273] pmic max77620 NVERC : 0x40
[0001.635] Welcome to L4T Cboot
[0001.639] Cboot Version: 00.00.2018.01-t210-40c3ff9c
[0001.644] calling constructors
U-Boot 2016.07-g93b56c0dd8 (Nov 22 2019 - 14:23:47 -0800)

Model: NVIDIA P3450-Porg
Board: NVIDIA P3450-PORG
Starting kernel ...

<hit enter to activate fiq debugger>
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.140-tegra (buildbrain@mobile-u64-2323) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP PREEMPT Fri Nov 22 14:32:45 PST 2019
[    0.000000] Boot CPU: AArch64 Processor [411fd071]

if you’re having the same pin design as Nano DevKit, they’ll outputting with J41 expansion header.
please also check Jetson Nano J41 Header Pinout for reference,

Hi JerryChang,

Thanks for the links. We checked our hardware design again and it seems the TTL to USB converter cable that we have is connected from pins 203/205.

So as per your answer, we should be able to see those boot-up logs on the host console, right? We use picocom.

But we don’t see these boot-up logs. Only after Nano has booted, we see a login prompt. So my question is: how to fetch these boot-up logs?

Is there a way to debug what’s going on?

hello jetson_user,

please refer to developer guide, did you applied Boot Time Reduction to disable logs?
you may examine the uart definitions, using $ dmesg | grep THS to check the mappings.
and, please also disassembler your dtb file into text file, $ dtc -I dtb -O dts -o output.txt tegra210.dtb for examination.

Hi JerryChang,

Thanks for pointing to the document!

The following is the output of the command dmesg | grep THS:

Also, from the host system ( at path: nvidia/nvidia_sdk/JetPack_4.2.1_Linux_GA_P3448-0020/Linux_for_Tegra/kernel/dtb) when I run the command: dtc -I dtb -O dts -o ou tput.txt tegra210-p3448-0002-p3449-0000-b00.dtb, I get an output which is attached here: output.txt (279.4 KB).

As seen from the output.txt file, I see the 70006040 component has status = “okay”.

Any suggestions as to how to approach this further?

hello jetson_user,

that seems correct,
did you also modify p3448-0000.conf.common file to change the command-line? it should by default output bootloader logs via uart-b.
here’s an external page for your reference, Jetson Nano Style - Serial Console - JetsonHacks.

Hi JerryChang,

Yes, we also modified the p3448-0000.conf.common file, and the command line looks like this:

CMDLINE_ADD=“console=ttyTHS1,115200n8 console=tty0 fbcon=map:0 net.ifnames=0”;

Even if we don’t modify the above line, the result is the same: no preboot/bootup UART logs.

We believe the nvgetty is trying to start a console on /dev/ttyTHS1. So our next step is to disable this service at rootfs (using chroot) and then flash the system again. But in any case, we should have seen those bootloader logs which you provided, right? We do not see them at all. The result is always the same: no uart preboot/boot-up logs, only a tegra-login prompt on boot.

Is there something else to check/change? Please let us know.

We believe that the electronics is correct, otherwise we wouldn’t have been able to view the tegra-login prompt.

Also, an alternative question.

If suppose the TTL to USB converter is soldered to pins 236/238, how do we get the preboot logs then? Where exactly in the device tree do we need to change?

hello jetson_user,

I’ll suspect it’s hardware design issue,
you don’t need extra configuration for bootloader logs on Nano DevKits, it just setup serial console via pins 203/205 and enable serial port utility to communicate with baud-rate 115200/8n1.

please refer to Nano’s device tree,
there’re three uart ports and you may also use uart-a to output logs.

        serial@70006000 { /* UART-A : UART1: Debug */
                compatible = "nvidia,tegra210-uart", "nvidia,tegra114-hsuart", "nvidia,tegra20-uart";
                /delete-property/ resets;
                /delete-property/ reset-names;
                status = "okay";

        serial@70006040 { /* UART-B : UART2 40 pin header */
                compatible = "nvidia,tegra114-hsuart";
                status = "okay";

        serial@70006200 { /* UART-C : UART3 : M.2 Key E */
                compatible = "nvidia,tegra114-hsuart";
                dma-names = "tx";
                nvidia,adjust-baud-rates = <921600 921600 100>;
                status = "okay";

Hi JerryChang,

Thanks for the dtsi file contents. We thought that if there was a hardware issue, we would not be able to view anything on the host console, or random characters. But we do see the following after a boot (during the boot, nothing is visible on the host console):

Ubuntu 18.04.2 LTS tegra-ubuntu ttyTHS1

tegra-ubuntu login:

This is if we enable nvgetty.service.

Also, the contents of the original jetson210-jetson-common.dtsi file that we had from Jetpack 4.2.1 are:

serial@70006000 {
compatible = “nvidia,tegra210-uart”, “nvidia,tegra114-hsuart”, “nvidia,tegra20-uart”;
/delete-property/ resets;
/delete-property/ reset-names;
status = “okay”;

serial@70006040 {
status = “okay”;

serial@70006200 {
status = “okay”;

We changed it accroding to what you sent, still we don’t see the UART logs.

Hi JerryChang,

Any updates on this one yet?

hello jetson_user ,

I’ve never seen this scenario,
could you please try moving to the latest release (i.e. JetPack-4.6.1) and reproduce the failure.

Hi jetson_user,

Are you connect TX/RX/GND pins on J44 (for Nano A02), or J50 (for Nano B01)?
Please reference detail user guide from here.

Hi carolyuu,

It seems you are referring to the Jetson Nano dev kits? We are working on the production modules, with custom carrier boards.

Hi JerryChang,

At the moment, we are unable to install Jetpack 4.6.1 on the host, but we are working on it. But we tried with Jetpack 4.4 and it didn’t work. Besides, we are sure that in the past we did obtain UART logs on Jetpack 4.2.1, but we unfortunately don’t have the design anymore. In that design the TX wire from the TTL to USB was probably directly soldered to either pin 203 or 236, but this whole setup was susceptible to physical damage. At the current moment we have better points on our custom carrier board to which the cable can be soldered, and these points connect to the Nano pins via the routes. So essentially, we are bringing out pins 203/205 of Jetson. But since we are not able to get the uart debug logs now, we were just wondering how to make sure that in kernel/device tree, the UART debug port is indeed mapped to pine 203/205. But like we discussed, as per you that seems to be the case, right?

Now we are trying to solder the TTL to USB cable to pins 236/38 on Nano. In that case what exactly should change? To bring the UART debug logs to port with pins 236/38 ?
Just in this file: hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-porg-p3448-common.dtsi, the 70006040 and 70006000 should be swapped?

hello jetson_user,

you don’t need changes.
as you can see per my previous comments #12. it’s device tree definition to have uarta route to debug port.
it’ll output logs with J44 on Nano-A02, or J50 on Nano-B01. we’ve also double confirmed with DevKit to obtain the logs,

it should be your hardware issue, please review your board design,