JetPack 6.1 Change Debug UART3 to UART1 on Custom Carrier

This is a follow up to my previous post that was prematurely closed without being resolved.

I am trying to redirect all debug and console output from Orin AGX’s UART3 to UART1 on Jetpack 6.1 (r36.4), including MB1, MB2, kernel and userspace, etc, but currently struggling just to get a normal userspace console on UART1

I have already tried everything in these posts but still do not see anything on the UART lines at all (with scope connected directly to the pins on the module CVM, K54 and K54):

My changes so far include:

    aliases {
-            serial0 = &tcu;
-            serial1 = &uarta;
+            serial0 = &uarta;
+            serial1 = &tcu;
    };

    chosen {
-            bootargs = "console=ttyTCU0,115200n8";
+            bootargs = "console=ttyS0,115200n8";
+            stdout-path = "serial0:115200n8";
    };

    bus@0 {
            serial@3100000 {
-                    compatible = "nvidia,tegra194-hsuart";
+                    compatible = "nvidia,tegra20-uart";
+                    current-speed = <115200>;
                    reset-names = "serial";
                    status = "okay";
            };

in source/hardware/nvidia/t23x/nv-public/tegra234-p3737-0000+p3701-0000.dts

CMDLINE_ADD="mminit_loglevel=4 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=ttyS0,115200"

in p3701.conf.common

                 init {
                        nafll_bpmp = <0xc5 0x00 0xc350000 0x00>;
                        nafll_seu1 = <0x14f 0x00 0x1c3a9000 0x00>;
                        bpmp_cpu_nic = <0x133 0xc5 0x00 0x00>;
                        fr_seu1 = <0x14b 0x14f 0x00 0x00>;
                        i2c_slow = <0x8a 0x121 0xffffffff 0x00>;
                        aon_i2c_slow = <0x75 0x121 0xffffffff 0x00>;
                        tach0 = <0x98 0x0e 0x30d400 0x00>;
                        tach1 = <0x16d 0x0e 0x30d400 0x00>;
                        i2c1 = <0x30 0x00 0x00 0x02>;
                        qspi0_2x_pm = <0xc0 0x00 0x00 0x02>;
                        sdmmc4 = <0x7b 0x00 0x00 0x02>;
                        seu1 = <0x150 0x00 0x00 0x08>;
-                        uartc = <0x9b 0x0 0x0 0x08>;
+                        uarta = <0x9b 0x66 0x1c1b40 0x08>;
                        pllref_vcoout = <0x120 0x00 0x00 0x0a>;
                        eqos_tx_divider = <0x19f 0x00 0xffffffff 0x00>;
                        eqos_axi = <0x20 0x00 0x7735940 0x02>;
                        eqos_tx = <0x23 0x00 0x00 0x02>;
                        eqos_macsec_tx = <0x19e 0x00 0x00 0x02>;
                        eqos_ptp_ref = <0x21 0x00 0xffffffff 0x02>;
                };
                lateinit {
                        ...
-                        uarta = <0x9b 0x66 0x00 0x00>;
                        uartb = <0x9c 0x66 0x00 0x00>;
+                        uartc = <0x9d 0x00 0x00 0x08>;
                        uartd = <0x9e 0x66 0x00 0x00>;
                        uarte = <0x9f 0x66 0x00 0x00>;

in bootloader/generic/tegra234-bpmp-3701-0005-3737-0000.dtb

The pinmux is also configured correctly where UART1 RX/TX pins are set correctly in from the spreadsheet:
Orin-main-pinmux.txt (65.7 KB)
Orin-main-gpio-default.txt (5.0 KB)

Here’s the dmesg and live device tree pulled from the Orin.
dmesg.txt (60.7 KB)
tree.txt (398.5 KB)

@KevinFFF @WayneWWW please advise

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, it appears that you are trying to redirect the debug and console output from UART3 to UART1 on a Jetson AGX Orin module running Jetpack 6.1 (r364) on a custom carrier board. You have already tried various solutions from previous posts but are still struggling to get a normal userspace console on UART1.

To resolve this issue, I will provide a comprehensive solution that compares the different approaches mentioned in the previous posts.

Kernel Command Line Update

Firstly, you need to update the kernel command line to specify the correct console device. You can do this by modifying the extlinux.conf file. Add the following lines to the CMDLINE section:

CMDLINE_ADD="console=ttyTCU0,115200 console=ttyAMA0,115200 console=tty0 firmware_classpath=/etc/firmware fbcon=map:0 net.ifnames=0"

This will set the console device to UART1 (ttyTCU0) and UART0 (ttyAMA0) with a baud rate of 115200.

Device Tree Update

Next, you need to update the device tree to reflect the changes. You can do this by modifying the p3701-0000+p3737-0000.dts file. Add the following lines to the &uart section:

&uart {
    status = "okay";
    nvidia,uart-ctrl = <&tegra_uart1>;
    nvidia,uart-ctrl-idx = <1>;
};

This will set the UART1 controller to be used for the debug console.

Pinmux Configuration

Ensure that the pinmux is configured correctly for UART1. You can do this by modifying the pinmux section in the Orin_main_pinmux.txt file. Set the UART1 RXTX pins to be used for the debug console.

Comparison of Approaches

The previous posts mentioned different approaches to achieve the same goal. Here’s a comparison of the approaches:

  • The first post suggests updating the extlinux.conf file and modifying the device tree. This approach is similar to the one I provided above.
  • The second post suggests updating the extlinux.conf file and modifying the pinmux section in the Orin_main_pinmux.txt file. This approach is also similar to the one I provided above.
  • The third post suggests modifying the p3701-0000+p3737-0000.dts file and updating the pinmux section in the Orin_main_pinmux.txt file. This approach is also similar to the one I provided above.

In summary, all the approaches suggest updating the kernel command line, device tree, and pinmux configuration to redirect the debug and console output from UART3 to UART1.

Additional Tips

  • Ensure that the UART1 RXTX pins are set correctly in the Orin_main_pinmux.txt file.
  • Verify that the dmesg and live device tree outputs match the expected configuration.
  • If you are still experiencing issues, try using a serial console tool like minicom or screen to verify that the debug console is working correctly.

I hope this comprehensive solution helps resolve the issue. If you have any further questions or concerns, please feel free to ask.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

Hi joseph.gao,

Are you using the custom carrier board with Jetpack 6.1 for AGX Orin?

Could you elaborate on the reason for this task?

I don’t think it is a valid approach as the debug UART output log from many firmwares.
All your current changes are for kernel device tree only.
You have to configure each binaries for debug log output, but not all firmwares are allowed for this customization.

Thank you for the fast response.

Yes, this is on a custom carrier board that’s already integrated into our product where the only way to get an outward facing console is through UART1.

I understand if some firmwares does not allow this change, we’d like to at minimum be able to use it as a kernel/userspace console for when we are unable to ssh into the system or be able to get as much debug info as possible from UART1 should it fail to boot.

Can you please help me by first getting a standard console running on UART1?

Hi Joseph,

As Kevin says it will be near impossible to redirect all debug output to UART1. Nonetheless I was able to get user space console up and running on UART1.

This is that I did:

Edited p3701.conf.common:

---
p3701.conf.common | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/p3701.conf.common b/p3701.conf.common
index 8a0aa0b..0ceb662 100644
--- a/p3701.conf.common
+++ b/p3701.conf.common
@@ -157,7 +157,7 @@ ODMDATA="gbe-uphy-config-0,hsstp-lane-map-3,hsio-uphy-config-0,nvhs-uphy-config-
CHIPID=0x23;
ITS_FILE=;
OVERLAY_DTB_FILE="L4TConfiguration.dtbo,tegra234-p3701-overlay.dtbo";
-CMDLINE_ADD="mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=tty0"
+CMDLINE_ADD="mminit_loglevel=4 console=ttyTHS1,115200n8 console=tty1 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 bl_prof_dataptr=2031616@0x82C610000 bl_prof_ro_ptr=65536@0x82C600000"
target_board="generic";
ROOTFSSIZE=55GiB;
ROOT_DEV="mmcblk0p1 ------------ internal eMMC.
-- 

Then flashed with this new p3701.conf.common

And then once booted up configured the console with a serial override:

sudo systemctl edit serial-getty@ttyTHS1.service

And edited the file to look something like this:

### Editing /etc/systemd/system/serial-getty@ttyTHS1.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
ExecStart=
ExecStart=-/sbin/agetty -o '-p -- \u' 115200 ttyTHS1 vt220

### Lines below this comment will be discarded

### /lib/systemd/system/serial-getty@.service
# #  SPDX-License-Identifier: LGPL-2.1-or-later
# #
# #  This file is part of systemd.

Restarted the daemon:

sudo systemctl daemon-reload
sudo systemctl restart serial-getty@ttyTHS1.service

Finally checked the status:

systemctl status serial-getty@ttyTHS1.service

And if it worked you should see something like this:

● serial-getty@ttyTHS1.service - Serial Getty on ttyTHS1
     Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/serial-getty@ttyTHS1.service.d
             └─override.conf
     Active: active (running) since Thu 2025-08-28 18:50:47 UTC; 36min ago
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             http://0pointer.de/blog/projects/serial-console.html
   Main PID: 5372 (login)
      Tasks: 0 (limit: 36502)
     Memory: 1.0M
        CPU: 95ms
     CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyTHS1.service
             ‣ 5372 /bin/login -p -- "" "" "" "" "" "" "" ""

Aug 28 18:50:47 ORINAGX2 systemd[1]: Started Serial Getty on ttyTHS1.

I know this was done on a custom carrier board, so I had to do some pinmux configuration, as you have done. I am also a bit fuzzy on the details, but I think this was all it took to get it up and running. Hopefully this helps!

Regards,

Jose Chavarria, Embedded software Engineer at RidgeRun

Thank you for pointing me in the right direction @Jose.Chavarria

I tried what you had suggested except with device node ttyS0 since I was using the tegra20-uart driver instead of tegra194-hsuart as suggested by @KevinFFF in this reply but was still not able to see anything on the UART lines.

I can see the console is present:

$ cat /proc/consoles
ttyS0                -W- (EC p a)    4:64
ramoops-1            -W- (E  p a)

ttyS0 is indeed connected to the correct uarta/UART1 serial peripheral:

$ ls -l /sys/class/tty/ttyS0
lrwxrwxrwx 1 root root 0 Nov 21  2023 /sys/class/tty/ttyS0 -> ../../devices/platform/bus@0/3100000.serial/tty/ttyS0

And the service set up in your suggestion is running:

● serial-getty@ttyS0.service - Serial Getty on ttyS0
     Loaded: loaded (/lib/systemd/system/serial-getty@.service; enabled-runtime; vendor preset: enabled)
     Active: active (running) since Fri 2026-02-06 17:47:21 UTC; 30min ago
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             http://0pointer.de/blog/projects/serial-console.html
   Main PID: 1188 (agetty)
      Tasks: 1 (limit: 74768)
     Memory: 200.0K
        CPU: 3ms
     CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyS0.service
             └─1188 /sbin/agetty -o "-p -- \\u" --keep-baud 115200,57600,38400,9600 ttyS0 vt220

Feb 06 17:47:21 bench-main systemd[1]: Started Serial Getty on ttyS0.

I will try again with reflashing back to using the tegra194-hsuart driver and ttyTHS1 node.

@Jose.Chavarria I reflashed it to use the tegra194-hsuart driver and ttyTHS0 node instead but still no luck.

@KevinFFF @Jose.Chavarria Please advise

Hi joseph.gao,

Please share the following information for further check.

  1. dmesg
  2. device tree
  3. kernel command line
$ cat /proc/cmdline

@KevinFFF here you go:

  1. dmesg.txt (59.5 KB)
  2. device-tree.txt (398.5 KB)
  3. root=PARTUUID=f004b9d8-7ce7-48a4-9470-561dfe0fec60 rw rootwait rootfstype=ext4 mminit_loglevel=4 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=ttyTCU0,115200 console=ttyTHS0,115200n8 bl_prof_dataptr=2031616@0x102C610000 bl_prof_ro_ptr=65536@0x102C600000

Could you refer to that thread and use nvidia,tegra20-uart as UART driver instead?

And add console=ttyS0,115200 in kernel command line.

This result looks good to me.
Is there any log output with this configuration?

@KevinFFF I was using the tegra20-uart driver in my original post:

and had this added as well:

but was not able to get anything out of UART1. Please advise.

Please configure the system to use the 8250 driver (nvidia,tegra20-uart) for the console, replacing the Tegra High Speed UART (nvidia,tegra194-hsuart)

The modifications required to enable the kernel console on UART1 are as follows:

1. Kernel cmdline : <Linux_for_Tegra>/p3701.conf.common

- CMDLINE_ADD="mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 video=efifb:off console=tty0 efi=runtime nvme.use_threaded_interrupts=1"
+ CMDLINE_ADD="mminit_loglevel=4 console=ttyS1,115200 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 video=efifb:off console=tty0 efi=runtime nvme.use_threaded_interrupts=1"

2. Device tree for both kernel and bootloader : <Linux_for_Tegra>/kernel/dtb/tegra234-p3737-0000+p3701-0000-nv.dtb

                serial@3100000 {
-                       compatible = "nvidia,tegra194-hsuart";
+                       compatible = "nvidia,tegra20-uart";
                        reg = <0x00 0x3100000 0x00 0x10000>;
                        interrupts = <0x00 0x70 0x04>;
                        clocks = <0x03 0x9b>;
                        resets = <0x03 0x64>;
-                       dmas = <0xee 0x08 0xee 0x08>;
-                       dma-names = "rx\0tx";
                        status = "okay";
                        reset-names = "serial";
                        phandle = <0x230>;
                };

3. Device tree for bpmp : <Linux_for_Tegra>/bootloader/generic/tegra234-bpmp-3701-0000-3737-0000.dtb

		init {
			nafll_bpmp = <0xc5 0x00 0xc350000 0x00>;
			nafll_seu1 = <0x14f 0x00 0x1c3a9000 0x00>;
			bpmp_cpu_nic = <0x133 0xc5 0x00 0x00>;
			fr_seu1 = <0x14b 0x14f 0x00 0x00>;
			i2c_slow = <0x8a 0x121 0xffffffff 0x00>;
			aon_i2c_slow = <0x75 0x121 0xffffffff 0x00>;
			tach0 = <0x98 0x0e 0x30d400 0x00>;
			tach1 = <0x16d 0x0e 0x30d400 0x00>;
			i2c1 = <0x30 0x00 0x00 0x02>;
			qspi0_2x_pm = <0xc0 0x00 0x00 0x02>;
			sdmmc4 = <0x7b 0x00 0x00 0x02>;
			seu1 = <0x150 0x00 0x00 0x08>;
			uartc = <0x9d 0x00 0x00 0x08>;
+			uarta = <0x9b 0x66 0x1c2000 0x08>;
			pllref_vcoout = <0x120 0x00 0x00 0x0a>;

..
		lateinit {
			nafll_dce = <0x155 0x00 0x10c8e000 0x00>;
			nafll_dla0_core = <0x12b 0x00 0xffffffff 0x00>;
			..
			uart_fst_mipi_cal = <0xa2 0x66 0x00 0x00>;
-			uarta = <0x9b 0x66 0x00 0x00>;
			uartb = <0x9c 0x66 0x00 0x00>;
			uartd = <0x9e 0x66 0x00 0x00>;


I have verified above workflow working to output kernel logs to UART1 on the AGX Orin devkit with Jetpack 6.2.2(r36.5)

@KevinFFF I followed your instructions but I’m still not able to see log output on UART1. I’m on JetPack 6.1, could there be something else I’m missing? Here’s the dmesg, device tree, and kernel command line on my current setup after your previous suggestion:
tree.txt (398.4 KB)
dmesg.txt (61.0 KB)
cmdline:

root=PARTUUID=d9b182cb-1b70-432a-9af8-7374f5671705 rw rootwait rootfstype=ext4 mminit_loglevel=4 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=ttyS0,115200n8 bl_prof_dataptr=2031616@0x102C610000 bl_prof_ro_ptr=65536@0x102C600000

Do you have the devkit to clarify if the issue is specific to your custom carrier board?
Or if the issue is caused from the difference between JP6.1 and JP6.2.2.

Could you just update exact the same as I shared?
e.g. your UART1(310000.serial is /dev/ttyS0, but it should be /dev/ttyS1 by default.)

You can run the following command to check if it has been added for console.

$ cat /proc/consoles

You would also need to update the bpmp-dtb or the clock would be unexpected with garbled messages.
The following command can be used to check the clock frequency.

cat /sys/kernel/debug/bpmp/debug/clk/clk_tree | grep -A1 uarta