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

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.
thanks

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.
thanks

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";
                console-port;
                sqa-automation-port;
                /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”;
console-port;
sqa-automation-port;
enable-rx-poll-timer;
/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.
thanks

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,

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

Hi JerryChang,

Okay, I understand now, thanks for clarifying, and sorry for the confusion. But let me put the question in another way:

What should I exactly change in order to make pins 203/205 the UART DEBUG port? I see by default the UART DEBUG port is on pins 236/238. Or in other words, I want UART A and B in the device tree to be swapped. This is because of the limitation of soldering that we now have, which is: we can only bring out pins 203/205 via soldering to TTL to USB converter. We want the UART DEBUG logs now (on pins 203/205), we don’t care about the console anymore.

hello jetson_user,

Nano CVM has 3 UARTs coming out.
for example,
UART2 for debug. it only has TX and RX available
UART0 on the M2 Key.
UART1 at 40 pin connector.

please remove console-port; from device tree if you’re going to use UART2 for no debug use-case,
for example,

diff --git a/kernel-dts/tegra210-porg-p3448-common.dtsi b/kernel-dts/tegra210-porg-p3448-common.dtsi
index 2a7d844..d4c7d59 100644
--- a/kernel-dts/tegra210-porg-p3448-common.dtsi
+++ b/kernel-dts/tegra210-porg-p3448-common.dtsi
@@ -697,7 +697,6 @@

        serial@70006000 { /* UART-A : UART1: Debug */
                compatible = "nvidia,tegra210-uart", "nvidia,tegra114-hsuart", "nvidia,tegra20-uart";
-               console-port;
                sqa-automation-port;

Hi JerryChang,

Thanks for the suggestion. We did this exact step, and unfortunately, still got no uart debug logs on the host. But after some time, we got a console login prompt.

I am assuming the serial@70006000 device is the one assigned to pins 236/238?

Is there anything else we can try?

hello jetson_user,

please try to update the bootargs to make console=ttyS0 and adding earlyprintk into the command-line.
thanks

Hi JerryChang,

Thank you for your support. We tried the above method, but still didn’t get the logs. It is the bootloader logs we needed, and we always received the logs on B01, just not on our carrier boards, so it was a matter of changing UART ports only.

So at the moment, we soldered the pins 236/238, instead of 203/205. And we have the UART logs now. We can close this topic, and I can continue pursuing our main issue on this link:

Hi JerryChang,

Could you perhaps help me with/advise me regarding our main issue at: Jetson Nano production module does not boot on custom carrier board, but does so on auvidea's.

The issue on this forum was to enable a solution for the main issue stated in the above link. So we can move the main issue. I posted my question over there but have not got a response yet.

let’s close this thread and moving to Topic 110823 for further supports.