Jetson Orin NX (P3767-0004) JP6.1 – UART1 (serial@3100000 / ttyTHS1) not receiving data, PR2/PR3 remain GPIO (pinmux anomaly)

Robotics & Edge Computing Jetson Systems Jetson Orin NX
,
1

Hi,

I am using a Jetson Orin NX (P3767-0004) with a custom carrier board that follows the standard 40-pin header layout (same mapping as P3768 devkit).

JetPack version:

cat /etc/nv_tegra_release
# R36.4.0 (JetPack 6.1)

Device tree compatible:

cat /proc/device-tree/compatible
nvidia,p3768-0000+p3767-0004
nvidia,p3767-0004
nvidia,tegra234

Goal

Use UART1 on the 40-pin header:

  • Pin 8 → PR2 → UART1_TX

  • Pin 10 → PR3 → UART1_RX

According to runtime device tree:

serial1 = "/bus@0/serial@3100000";

And:

udevadm info -a -n /dev/ttyTHS1
→ iomem_base = 0x3100000

So /dev/ttyTHS1 maps to serial@3100000 (UART1 / uarta).

Observed Anomalies

1️⃣ UART clock behavior

Before opening ttyTHS1:

uarta  0  0  0

After opening ttyTHS1:

sudo cat /sys/kernel/debug/clk/clk_summary | grep uarta

uarta  1  1  0  1841986

So the UART1 clock becomes enabled when the device is opened.

This suggests:

  • Driver is loaded

  • Peripheral is present

  • Clock tree is functional

2️⃣ PR2 / PR3 appear as GPIO

However:

sudo gpioinfo | grep PR.02
sudo gpioinfo | grep PR.03

line 110: "PR.02" unused input active-high
line 111: "PR.03" unused input active-high

And in pinctrl debug:

sudo cat /sys/kernel/debug/pinctrl/2430000.pinmux/pinmux-pins | grep PR2
sudo cat /sys/kernel/debug/pinctrl/2430000.pinmux/pinmux-pins | grep PR3

(MUX UNCLAIMED) (GPIO UNCLAIMED)

This indicates:

  • Pins are not claimed by UART driver

  • They still behave as GPIO

  • No pinctrl state is applied for uart1_tx_pr2 / uart1_rx_pr3

3️⃣ No data received on ttyTHS1

When external data is sent to Pin 10 (UART1_RX), nothing appears on:

sudo stty -F /dev/ttyTHS1 115200 raw -echo
sudo cat /dev/ttyTHS1

No data, no framing errors, no activity.

4️⃣ devmem test does not change pin ownership

Register addresses:

  • PR2 → 0x2430098

  • PR3 → 0x243009C

Reading:

sudo busybox devmem 0x2430098
sudo busybox devmem 0x243009C

Modifying via devmem does not cause the pins to be claimed by UART, and they still appear as GPIO in gpioinfo.

5️⃣ Device tree runtime inspection

Decompiled runtime DT shows:

  • serial@3100000 status = “okay”

  • No explicit pinmux node for uart1_tx_pr2 / uart1_rx_pr3 inside pinmux@2430000

It appears no pinctrl configuration for UART1 is applied at boot.

Questions

  1. On JetPack 6.1 (R36.x), is UART1 on the 40-pin header disabled by default?

  2. Is pinmux for PR2/PR3 now controlled exclusively by MB1 BCT in JP6.x?

  3. Should I modify:

    • nv-platform/tegra234-p3768-0000+p3767-xxxx-nv-common.dtsi

    • Or regenerate pinmux via the official spreadsheet and reflash?

  4. Is this behavior expected for custom carrier boards without EEPROM override?

Summary

  • UART1 peripheral exists

  • Clock enables correctly

  • ttyTHS1 is mapped correctly

  • But PR2/PR3 remain GPIO

  • No data received

It appears that pinmux for UART1 is not configured at boot on JP6.1.

Any guidance on the correct way to enable UART1 pinmux on P3767-0004 (JP6.1) would be appreciated.

Thanks.

3

Hi musthofaanwari0110,

Please use pinmux spreadsheet to configure the pinmux for UART1 as you are using the custom carrier board.

I would also suggest verifying the UART loopback test. (i.e. please short UART TX/RX)
e.g.

$ sudo su
# stty -F /dev/ttyTHS1 115200 raw -echo
# cat /dev/ttyTHS1 &
# echo "test" > /dev/ttyTHS1
5

Hi,

Thank you for your previous guidance.

I would like to clarify my situation more precisely.

I am using a custom carrier board with P3767-0004 (JetPack 6.1).
However, the 40-pin header routing is designed to follow the standard P3768 devkit mapping.

Because of this, my expectation is that the default 40-pin configuration (GPIO/UART/SPI/I2C) should behave the same as the official devkit.

However, I am observing the following anomalies:

  • UART1 (serial@3100000 / ttyTHS1) is enabled

  • The uarta clock becomes active when opening /dev/ttyTHS1

  • But PR2/PR3 (Pin 8/10 on 40-pin header) remain GPIO in gpioinfo

  • pinctrl shows (MUX UNCLAIMED)

  • No data is received on ttyTHS1

  • Previously, I also observed similar inconsistencies with GPIO behavior

This makes me suspect that the default 40-pin pinmux configuration is not being applied at boot.

Since my carrier board follows the standard P3768 40-pin routing, I would like to:

Use the default NVIDIA 40-pin pinmux configuration for JP6.1 (R36.x) without custom remapping.

Could you please clarify:

  1. Which official pinmux spreadsheet corresponds to P3767-0004 for JP6.1?

  2. If I want to use the default P3768 configuration, do I need to regenerate pinmux files, or can I reuse the default NVIDIA BCT configuration?

  3. In JP6.x, is pinmux fully controlled by MB1 BCT and therefore requires reflashing?

  4. If I want to ensure the board uses the exact default 40-pin configuration from NVIDIA devkit, what is the correct workflow?

My goal is not to customize pinmux, but to ensure the board uses the official default 40-pin behavior consistent with P3768.

Thank you.

6

Hi,

I would like to provide additional clarification regarding my setup.

After checking the system information, I realized that I am not running the stock NVIDIA L4T image.

Here is the output:

cat /etc/nv_tegra_release

Output:

R36.4.0 (JetPack 6.1)

Seeed Image Name: mfi_recomputer-orin-nx-8g-j401-6.1-36.4.0-2024-12-25.tar.gz

And:

cat /etc/nv_boot_control.conf

Output:

TNSPEC … recomputer-orin-j401

COMPATIBLE_SPEC … recomputer-orin-j401

So this is a Seeed reComputer J401 image, not the stock NVIDIA devkit image.

Although the 40-pin header routing is designed to follow the standard P3768 layout, it appears the board is configured as a custom carrier (recomputer-orin-j401), and therefore may not use the default NVIDIA P3768 pinmux/BCT configuration.

Given this information:

  • serial@3100000 (UART1) is enabled

  • uarta clock becomes active when opening /dev/ttyTHS1

  • But PR2/PR3 remain GPIO in gpioinfo

  • pinctrl shows MUX UNCLAIMED

  • No data is received on ttyTHS1

It now seems possible that the default 40-pin pinmux configuration is not being applied due to the custom board configuration from Seeed.

Could you please clarify:

  1. For JP6.1 with recomputer-orin-j401, is the 40-pin default pinmux different from P3768 devkit?

  2. If I want behavior identical to the official P3768 devkit, should I flash the stock NVIDIA L4T image instead?

  3. Or is it recommended to regenerate pinmux via spreadsheet specifically for this board?

Thank you.

7

Sorry that we are not clear about the custom board design as they are not developed by us.
Please check with your vendor for details and request them for pinmux spreadsheet of the custom board.

I’m not sure if the official L4T image working on your custom carrier board as there may be the HW difference between the devkit and the custom board.

As the board is not designed by you, please request your vendor for those information.