Replacing Debug serial with normal UART

[Gorgo90]

Jetpack: 5.1.1
NVIDIA: Orin NX
Carrier board: Seeedstudio A603

Hi all,
According to the A603 datasheet, my carrier board has 3 UARTs:
UART0 for the M2 KEY E, UART1 on the 14PIN W7 connector and UART2 on the 40 PIN W8 connector.

I can use correctly UART2 on Pins 8/10 communicating on /dev/ttyTHS0.

In order to interface a second serial device, I’d like to use the TX/RX on the 14Pin W7 connector.

I tried to dig into the issue and I found multiple threads about it, specially for Xavier NX.
I understood I have to disable the combined-uart in order to use the debug serial as a classic UART.

Following Repurpose Debug UART for 'normal' comms on Xavier NX - #6 by JerryChang I couldn’t flash my ORIN NX succesfully. It goes into timeout when it tries to connect to ssh during the flashing procedure. I guess this is the issued described here.

So I tried to edit the DTB after flashing.

0. Added the user to dialout
1. I disabled combined-uart’s status
2. I set tegra20-uart to serial@c280000 and I set its status to okay
3. I updated chosen bootargs to

bootargs = “console=ttyS2,115200 earlycon=uart8250,mmio32,0x0c280000”;

4. I disabled nvgetty service
5. In extlinux.conf I replaced

APPEND ${cbootargs} root=PARTUUID=7639c47a-8155-4bc3-83d2-99c160e675c9 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0

with

APPEND ${cbootargs} root=PARTUUID=7639c47a-8155-4bc3-83d2-99c160e675c9 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyS2,115200n8 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0

After rebooting I don’t see ttyTCU0 anymore and I see ttyS2.

This is dmesg:

nvidia@nvidia-orin:~$ sudo dmesg | grep tty
[sudo] password for nvidia:
[ 0.000000] Kernel command line: root=PARTUUID=7639c47a-8155-4bc3-83d2-99c160e675c9 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyS2,115200n8 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0
[ 0.000830] printk: console [tty0] enabled
[ 0.282189] 31d0000.serial: ttyAMA0 at MMIO 0x31d0000 (irq = 64, base_baud = 0) is a SBSA
[ 3.320748] printk: console [ttyS2] disabled
[ 3.320831] c280000.serial: ttyS2 at MMIO 0xc280000 (irq = 61, base_baud = 114285) is a Tegra
[ 6.779827] printk: console [ttyS2] enabled
[ 6.792509] 3100000.serial: ttyTHS0 at MMIO 0x3100000 (irq = 17, base_baud = 0) is a TEGRA_UART
[ 6.809069] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 62, base_baud = 0) is a TEGRA_UART
[ 6.825624] 3140000.serial: ttyTHS4 at MMIO 0x3140000 (irq = 63, base_baud = 0) is a TEGRA_UART
[ 9.148888] systemd[1]: Created slice system-serial\x2dgetty.slice.

As test I’m using

sudo minicom -b115200 -D/dev/ttyS2 -H #ORIN
or
sudo minicom -b9600 -D/dev/ttyS2 -H #ORIN
sudo echo -e “uud1\r” > /dev/ttyUSB0 #Host

But I don’t see any bytes on minicom.
I tried to remove console=ttyS2,115200n8 from bootargs.

My new dmesg is:

nvidia@nvidia-orin:~$ sudo dmesg | grep tty
[ 0.000000] Kernel command line: root=PARTUUID=7639c47a-8155-4bc3-83d2-99c160e675c9 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0
[ 0.000839] printk: console [tty0] enabled
[ 0.282433] 31d0000.serial: ttyAMA0 at MMIO 0x31d0000 (irq = 64, base_baud = 0) is a SBSA
[ 3.611531] c280000.serial: ttyS2 at MMIO 0xc280000 (irq = 61, base_baud = 114285) is a Tegra
[ 3.612246] 3100000.serial: ttyTHS0 at MMIO 0x3100000 (irq = 17, base_baud = 0) is a TEGRA_UART
[ 3.612906] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 62, base_baud = 0) is a TEGRA_UART
[ 3.613522] 3140000.serial: ttyTHS4 at MMIO 0x3140000 (irq = 63, base_baud = 0) is a TEGRA_UART
[ 4.802881] systemd[1]: Created slice system-serial\x2dgetty.slice.

I don’t see any bytes on minicom BUT the opposite is working now:

sudo echo -e “uud1\r” > /dev/ttyS2 #ORIN
sudo minicom -b115200 -D/dev/ttyUSB0 -H #Host

I get 75 75 64 31 0d 0d 0a.

The opposite is not working though and I have no idea why. The wiring is ok between the serial adapter and the Orin (with ttyTHS0 I can send AND receive).

Thank you!

DTS File: kernel_tegra234-p3767-0000-p3509-a02.dts.txt (413.6 KB)

[KevinFFF]

Hi Gorgo90,

Please refer to the following thread for UART mapping for Orin NX.

It seems you are using the custom carrier board so that there should be minor difference from the devkit.

Do you want to want to disable UART2 (uartc@c280000), which is used for combined UART to output the log?
and you want to use it as normal UART?
Actually, we don’t suggest for this use case because you have to disable combined UART from early boot, bootloader, kernel respectively and we don’t verify its performance.

@Gorgo90

I don’t see any bytes on minicom BUT the opposite is working now:

Do you mean the data could be received on Orin NX but could not received from host?

[Gorgo90]

Hi @KevinFFF
Which thread are you talking about? Missing link?
I saw the table you shared:

There you wrote

• UART0 => UART2(PX04, PX05, PX06, PX07): uartb@3110000 (serial1) - Unused => To M.2 Key E
• UART1 => UART1(PR02, PR03, PR04, PR05): uarta@3100000 (serial0) - /dev/ttyTHS0 => General UART
• UART2 => UART3(PCC05, PCC06): uartc@c280000 (serial2) - /dev/ttyTCU0 => Debug

According to my DTB

• uartb@3110000 (serial1) is disabled and I think It’s what Seeedstudio calls UART0_RXD, UART0_TXD, UART0_CTS, UART0_RTS (W13 PIN 22,24,26,28)
• uarta@3100000 (serial0) - /dev/ttyTHS0 was active and I know that ttyTHS0 is the interface in the 40PIN W8 interface, pin 8 and 10 that referees to ORIN’s pin 203/205 (UART1).
  Here I don’t why they report UART2 as Ball names though.

• uartc@280000 (serial2) was disabled and I changed its status as reported in my previous post.
  It should correspond to W7 pins named UART2_TXD_LS and UART2_RXD_LS (236 and 238) as reported in the table in the previous post.

Do you want to want to disable UART2 (uartc@c280000 ), which is used for combined UART to output the log?
and you want to use it as normal UART?

I have some problems in answering this question. UART2, according to the original DTB, was already disabled, but combined-uart was enabled. So I’m not sure if I must disable or enable UART2.
What I think I understood is that I need to disable combined UART in order to use the Debug PINS as normal UART (according to other instructions in this forum).
Btw, yes, I’d like to transmit and receive data using the former debug serial.

Actually, we don’t suggest for this use case because you have to disable combined UART from early boot, bootloader, kernel respectively and we don’t verify its performance.

I understand the risk, but I’d like to test it if possible. At least I expect I can see the byte in both TX and RX though.

Do you mean the data could be received on Orin NX but could not received from host?

The opposite. I can send a string into /dev/ttyS2 (ORIN) and I can read it correctly on Host side.

sudo echo -e “uud1\r” > /dev/ttyS2 #ORIN
sudo minicom -b115200 -D/dev/ttyUSB0 -H #Host

Thank you!

[KevinFFF]

@Gorgo90

Which thread are you talking about? Missing link?

Sorry for missing update the link: OrinNX : How to check UART is working? - #3 by KevinFFF

@Gorgo90

I understand the risk, but I’d like to test it if possible. At least I expect I can see the byte in both TX and RX though.

Please refer to the following thread for this use case, which is for the Xavier NX. You might need to adjust them for Orin NX.
Disabling combined UART in JetPack 5.1.1 on Xavier NX - #13 by dan.madill

[Gorgo90]

Hi @KevinFFF ,
Please note that in my previous thread I had already pinned out the thread you linked, also commenting the table and the corresponding UARTs configuration.

In my original post I did also linked the last thread you mentioned for the Xavier NX.
The corresponding procedure for the ORIN NX is preventing the flashing though. (SSH timeouts).
That’s why I tried to disabled the serial debug AFTER flashing (steps 0-5). I partially did it.
It’s actually what @dan.madill did eventually in this thread (Disabling combined UART in JetPack 5.1.1 on Xavier NX - #24 by dan.madill) but apparently his UART is working in both directions (TX/RX).

Other ideas regarding the UART RX misbehaving, or any other tests are welcome.

Thank you!

[KevinFFF]

@Gorgo90

The corresponding procedure for the ORIN NX is preventing the flashing though. (SSH timeouts).

Do you mean that you would flash failed after applying the changes to disable combined UART?
If so, please share the full flash log for further check.
and please let me know which change would cause the flash failed.

For the most SSH timeout issue, it may be caused from the boot issue so that please also share the serial console log from your board at this moment.

[Gorgo90]

Hi @KevinFFF
I double checked my previous procedure.
Actually It used to timeout If I tried to mimic THESE edits:

Disabling combined UART in JetPack 5.1.1 on Xavier NX

I made the changes below to the five files only. The net result was that the Xavier NX did not boot and did not even enter the UEFI shell. I have attached the log from the debug UART (which is clearly not fully disabled) debug_uart.log (10.4 KB). JetPack 5.1.1 Device Tree Changes p3668.conf.common Changed: TBCDTB_FILE=tegra194-p3668-all-p3509-0000.dtb; CMDLINE_ADD="console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0"; target_board="t186ref"; to: TBCDTB_FILE=tegra194-p3668-a…

I noticed that you linked the following edits (same topic but different answer), e.g. THESE. I’ll try it in this answer then.

Disabling combined UART in JetPack 5.1.1 on Xavier NX

I made the changes below to the three files only. The net result was that the Xavier NX does boot successfully but the UART is clearly still being used as a debug UART during boot. I have attached the log from the debug UART debug_port.log (12.1 KB). Also note that /dev/ttyTCU0 still exists so the combined UART is still being created. JetPack 5.1.1 Device Tree Changes p3668.conf.common Changed: TBCDTB_FILE=tegra194-p3668-all-p3509-0000.dtb; CMDLINE_ADD="console=ttyTCU0,115200n8 console=tt…

So, a premise before continuing:
I downloaded and sourced (source_sync.sh) the Jetpack 5.1.1 Linux_for_Tegra.
I then compiled the kernel with:

cd sources/kernel/kernel-5.10/
sudo make ARCH=arm64 LOCALVERSION=-tegra CROSS_COMPILE=${CROSS_COMPILE_AARCH64} tegra_defconfig
sudo make ARCH=arm64 LOCALVERSION=-tegra CROSS_COMPILE=${CROSS_COMPILE_AARCH64} menuconfig
sudo make ARCH=arm64 LOCALVERSION=-tegra CROSS_COMPILE=${CROSS_COMPILE_AARCH64} -j16
sudo make ARCH=arm64 LOCALVERSION=-tegra CROSS_COMPILE=${CROSS_COMPILE_AARCH64} INSTALL_MOD_PATH=…/…/…/rootfs/ modules_install
cp --verbose arch/arm64/boot/Image …/…/…/kernel/Image
cp --verbose arch/arm64/boot/dts/nvidia/*.dtb …/…/…/kernel/dtb/
cd …/…/…/rootfs/
sudo tar --owner root --group root -cjf kernel_supplements.tbz2 lib/modules
cp kernel_supplements.tbz2 …/kernel/kernel_supplements.tbz2

I then overwrited the ‘pheriperal drivers’ provided by seeedstudio, e.g. custom

• bootloader/tegra234-mb1-bct-gpio-p3767-hdmi-a03.dtsi
• bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi
• kernel/Image
• kernel/dtb/tegra234-p3767-0000-p3509-a02.dtb
• kernel/dtb/tegra234-p3767-0001-p3509-a02.dtb

Subsequently, I edited the following files:

p3767.conf.common

CMDLINE_ADD=“mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0”

to

CMDLINE_ADD=“mminit_loglevel=4 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0”

./bootloader/t186ref/tegra234-bpmp-3767-0000-a02-3509-a02.dtb
and
./bootloader/tegra234-bpmp-3767-0000-a02-3509-a02.dtb

Removed:

serial {
port = <0x03>;
has_input;

  combined-uart {
  	enabled;
  };

};

./kernel/dtb/tegra234-p3767-0000-p3509-a02.dtb
and
./bootloader/tegra234-p3767-0000-p3509-a02.dtb

From

combined-uart {
compatible = “nvidia,tegra194-tcu”;
reg = <0x00 0x3c10000 0x00 0x04 0x00 0xc168000 0x00 0x04 0x00 0x3c00000 0x00 0x1000>;
interrupts = <0x00 0x78 0x04>;
mboxes = <0x07 0x01 0x00 0x5d 0x01 0x80000001>;
mbox-names = “rx\0tx”;
console-port;
combined-uart;
status = “okay”;
};

to

combined-uart {
compatible = “nvidia,tegra194-tcu”;
reg = <0x00 0x3c10000 0x00 0x04 0x00 0xc168000 0x00 0x04 0x00 0x3c00000 0x00 0x1000>;
interrupts = <0x00 0x78 0x04>;
mboxes = <0x07 0x01 0x00 0x5d 0x01 0x80000001>;
mbox-names = “rx\0tx”;
console-port;
combined-uart;
status = “disabled”;
};

And flashed with:

sudo ADDITIONAL_DTB_OVERLAY_OPT=“BootOrderNvme.dtbo” ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p “-c bootloader/t186ref/cfg/flash_t234_qspi.xml” --showlogs --network usb0 p3509-a02+p3767-0000 internal

flashlog1-11.log (290.2 KB)

/dev/ttyTCU0 is still present.
In fact, /boot/dtb/kernel_tegra234-p3767-0000-p3509-a02.dtb still contains:

combined-uart {
compatible = “nvidia,tegra194-tcu”;
reg = <0x00 0x3c10000 0x00 0x04 0x00 0xc168000 0x00 0x04 0x00 0x3c00000 0x00 0x1000>;
interrupts = <0x00 0x78 0x04>;
mboxes = <0x07 0x01 0x00 0x5d 0x01 0x80000001>;
mbox-names = “rx\0tx”;
console-port;
combined-uart;
status = “okay”;
};

My feeling is that the Seeedstudio’s kernel/Image is overwriting my edits above. Shall I recompile after overwriting the new files from Seeedstudio?

[KevinFFF]

Do you mean that you are trying to modify the kernel image/dtb for the custom carrier board but the board is not designed from you?
If so, i would suggest you just modifying the compiled dtb and related contents instead of re-build kernel image/dtb.

I would also suggest that you apply the changes one-by-one so that you would know which modification causes the flash/boot failed.

From your flash log, it seems you could flash the board successfully.

[Gorgo90]

Hi @KevinFFF
Yes, I do. I’m not the designer of the carrier board.
I did modify directly the dtb after flashing a vanilla kernel image (+ Seeedstudio drivers and modifications I mentioned above) and what’s actually I did in the very first topic (Replacing Debug serial with normal UART)

Please check again what’s after ‘So I tried to edit the DTB after flashing.’

I would also suggest that you apply the changes one-by-one so that you would know which modification causes the flash/boot failed. From your flash log, it seems you could flash the board successfully.

I agree with you, but if editing the dtb after flashing is a viable solution, let’s start with the working Image + editing the DTB, as I was trying at the beginning.

I hope you got a clearer idea about my situation now :)

[KevinFFF]

Thanks for your clarification.

@Gorgo90

I agree with you, but if editing the dtb after flashing is a viable solution, let’s start with the working Image + editing the DTB, as I was trying at the beginning.

Please let me know your result and also share the full serial console log after the modification. As my understanding, there might be still few messages in bootloader but you could disable the messages after kernel up.

[Gorgo90]

Starting from Jetpack 5.1.1 + Seeedstudio’s pheriperal drivers, I did:

0. Added the user to dialout

1. I converted /boot/dtb/kernel_tegra234-p3767-0000-p3509-a02.dtb to DTS and
   1.a I disabled combined-uart’s status
   1.b I set tegra20-uart to serial@c280000 and I set its status to okay
   1.c I updated chosen bootargs to

bootargs = “console=ttyS2,115200 earlycon=uart8250,mmio32,0x0c280000”;

2. I disabled nvgetty service
3. In extlinux.conf I replaced

APPEND ${cbootargs} root=PARTUUID=7639c47a-8155-4bc3-83d2-99c160e675c9 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0

with

APPEND ${cbootargs} root=PARTUUID=7639c47a-8155-4bc3-83d2-99c160e675c9 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0

I then tested TX/RX communication via Serial/USB adapter to my laptop.

sudo echo -e “uud1\r” > /dev/ttyS2 #ORIN
sudo minicom -b115200 -D/dev/ttyUSB0 -H #Host

I get 75 75 64 31 0d 0d 0a.

So I could SEND data from the ORIN to the laptop.
If I try the same commands FROM the laptop TO the Orin, I don’t see any data.

Full dmesg: dmesg_nvidia.log (70.1 KB)
Full boot log: bootlog.log (28.6 KB)

The boot log is gotten it via the same serial/usb adapter I used for the TX/RX tests above to the same Serial debug that eventually it’s shown as ttyS2 in the system.

[KevinFFF]

@Gorgo90

Full boot log: bootlog.log (28.6 KB)

It seems the most debug messages have been disabled, just left some messages from MB1 and MB2.

@Gorgo90

If I try the same commands FROM the laptop TO the Orin, I don’t see any data.

Do you run the stty command before send the data?
Have you also tried to verify the UART loopback test by shorting TXD/RXD?

[Gorgo90]

@KevinFFF

It seems the most debug messages have been disabled, just left some messages from MB1 and MB2.

Is it ok?

@KevinFFF

Do you run the stty command before send the data?
Have you also tried to verify the UART loopback test by shorting TXD/RXD?

No I didn’t use any stty command before.

I’ve just tried to verify the UART loopback (Wiring TXD/RXD together) with the following commands:

nvidia@nvidia-orin:~$ sudo su
root@nvidia-orin:/home/nvidia# stty -F /dev/ttyS2 115200 raw -echo
root@nvidia-orin:/home/nvidia# cat /dev/ttyS2 &
[1] 3348
root@nvidia-orin:/home/nvidia# echo “test” > /dev/ttyS2

I don’t see any output, confirming that RXD is not working somehow.

[KevinFFF]

@Gorgo90

Is it ok?

Normally, you would interact with UART after kernel boot up so that I would be enough for you to disable all combined UART messages after kernel is up.

Could you share the result of the following command on your board?

$ ls-l /dev/tty*

[Gorgo90]

Correct, I don’t need to use RX/TX before kernel is up.

@KevinFFF

Could you share the result of the following command on your board?

$ ls-l /dev/tty*

nvidia@nvidia-orin:~$ ls -l /dev/tty*
crw-rw-rw- 1 root tty 5, 0 Nov 7 07:46 /dev/tty
crw–w---- 1 root tty 4, 0 Nov 7 07:46 /dev/tty0
crw–w---- 1 root tty 4, 1 Nov 7 07:46 /dev/tty1
crw–w---- 1 root tty 4, 10 Nov 7 07:46 /dev/tty10
crw–w---- 1 root tty 4, 11 Nov 7 07:46 /dev/tty11
crw–w---- 1 root tty 4, 12 Nov 7 07:46 /dev/tty12
crw–w---- 1 root tty 4, 13 Nov 7 07:46 /dev/tty13
crw–w---- 1 root tty 4, 14 Nov 7 07:46 /dev/tty14
crw–w---- 1 root tty 4, 15 Nov 7 07:46 /dev/tty15
crw–w---- 1 root tty 4, 16 Nov 7 07:46 /dev/tty16
crw–w---- 1 root tty 4, 17 Nov 7 07:46 /dev/tty17
crw–w---- 1 root tty 4, 18 Nov 7 07:46 /dev/tty18
crw–w---- 1 root tty 4, 19 Nov 7 07:46 /dev/tty19
crw–w---- 1 nvidia tty 4, 2 Nov 7 07:46 /dev/tty2
crw–w---- 1 root tty 4, 20 Nov 7 07:46 /dev/tty20
crw–w---- 1 root tty 4, 21 Nov 7 07:46 /dev/tty21
crw–w---- 1 root tty 4, 22 Nov 7 07:46 /dev/tty22
crw–w---- 1 root tty 4, 23 Nov 7 07:46 /dev/tty23
crw–w---- 1 root tty 4, 24 Nov 7 07:46 /dev/tty24
crw–w---- 1 root tty 4, 25 Nov 7 07:46 /dev/tty25
crw–w---- 1 root tty 4, 26 Nov 7 07:46 /dev/tty26
crw–w---- 1 root tty 4, 27 Nov 7 07:46 /dev/tty27
crw–w---- 1 root tty 4, 28 Nov 7 07:46 /dev/tty28
crw–w---- 1 root tty 4, 29 Nov 7 07:46 /dev/tty29
crw–w---- 1 root tty 4, 3 Nov 7 07:46 /dev/tty3
crw–w---- 1 root tty 4, 30 Nov 7 07:46 /dev/tty30
crw–w---- 1 root tty 4, 31 Nov 7 07:46 /dev/tty31
crw–w---- 1 root tty 4, 32 Nov 7 07:46 /dev/tty32
crw–w---- 1 root tty 4, 33 Nov 7 07:46 /dev/tty33
crw–w---- 1 root tty 4, 34 Nov 7 07:46 /dev/tty34
crw–w---- 1 root tty 4, 35 Nov 7 07:46 /dev/tty35
crw–w---- 1 root tty 4, 36 Nov 7 07:46 /dev/tty36
crw–w---- 1 root tty 4, 37 Nov 7 07:46 /dev/tty37
crw–w---- 1 root tty 4, 38 Nov 7 07:46 /dev/tty38
crw–w---- 1 root tty 4, 39 Nov 7 07:46 /dev/tty39
crw–w---- 1 root tty 4, 4 Nov 7 07:46 /dev/tty4
crw–w---- 1 root tty 4, 40 Nov 7 07:46 /dev/tty40
crw–w---- 1 root tty 4, 41 Nov 7 07:46 /dev/tty41
crw–w---- 1 root tty 4, 42 Nov 7 07:46 /dev/tty42
crw–w---- 1 root tty 4, 43 Nov 7 07:46 /dev/tty43
crw–w---- 1 root tty 4, 44 Nov 7 07:46 /dev/tty44
crw–w---- 1 root tty 4, 45 Nov 7 07:46 /dev/tty45
crw–w---- 1 root tty 4, 46 Nov 7 07:46 /dev/tty46
crw–w---- 1 root tty 4, 47 Nov 7 07:46 /dev/tty47
crw–w---- 1 root tty 4, 48 Nov 7 07:46 /dev/tty48
crw–w---- 1 root tty 4, 49 Nov 7 07:46 /dev/tty49
crw–w---- 1 root tty 4, 5 Nov 7 07:46 /dev/tty5
crw–w---- 1 root tty 4, 50 Nov 7 07:46 /dev/tty50
crw–w---- 1 root tty 4, 51 Nov 7 07:46 /dev/tty51
crw–w---- 1 root tty 4, 52 Nov 7 07:46 /dev/tty52
crw–w---- 1 root tty 4, 53 Nov 7 07:46 /dev/tty53
crw–w---- 1 root tty 4, 54 Nov 7 07:46 /dev/tty54
crw–w---- 1 root tty 4, 55 Nov 7 07:46 /dev/tty55
crw–w---- 1 root tty 4, 56 Nov 7 07:46 /dev/tty56
crw–w---- 1 root tty 4, 57 Nov 7 07:46 /dev/tty57
crw–w---- 1 root tty 4, 58 Nov 7 07:46 /dev/tty58
crw–w---- 1 root tty 4, 59 Nov 7 07:46 /dev/tty59
crw–w---- 1 root tty 4, 6 Nov 7 07:46 /dev/tty6
crw–w---- 1 root tty 4, 60 Nov 7 07:46 /dev/tty60
crw–w---- 1 root tty 4, 61 Nov 7 07:46 /dev/tty61
crw–w---- 1 root tty 4, 62 Nov 7 07:46 /dev/tty62
crw–w---- 1 root tty 4, 63 Nov 7 07:46 /dev/tty63
crw–w---- 1 root tty 4, 7 Nov 7 07:46 /dev/tty7
crw–w---- 1 root tty 4, 8 Nov 7 07:46 /dev/tty8
crw–w---- 1 root tty 4, 9 Nov 7 07:46 /dev/tty9
crw-rw---- 1 root dialout 204, 64 Nov 7 07:46 /dev/ttyAMA0
crw–w---- 1 root tty 235, 0 Nov 7 07:46 /dev/ttyGS0
crw-rw---- 1 root dialout 4, 64 Nov 7 07:46 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 Nov 7 07:46 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Nov 7 07:46 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Nov 7 07:46 /dev/ttyS3
crw-rw---- 1 root dialout 239, 0 Nov 7 07:46 /dev/ttyTHS0
crw-rw---- 1 root dialout 239, 3 Nov 7 07:46 /dev/ttyTHS3
crw-rw---- 1 root dialout 239, 4 Nov 7 07:46 /dev/ttyTHS4
crw------- 1 root root 3, 0 Nov 7 07:46 /dev/ttyp0
crw------- 1 root root 3, 1 Nov 7 07:46 /dev/ttyp1
crw------- 1 root root 3, 2 Nov 7 07:46 /dev/ttyp2
crw------- 1 root root 3, 3 Nov 7 07:46 /dev/ttyp3
crw------- 1 root root 3, 4 Nov 7 07:46 /dev/ttyp4
crw------- 1 root root 3, 5 Nov 7 07:46 /dev/ttyp5
crw------- 1 root root 3, 6 Nov 7 07:46 /dev/ttyp6
crw------- 1 root root 3, 7 Nov 7 07:46 /dev/ttyp7
crw------- 1 root root 3, 8 Nov 7 07:46 /dev/ttyp8
crw------- 1 root root 3, 9 Nov 7 07:46 /dev/ttyp9
crw------- 1 root root 3, 10 Nov 7 07:46 /dev/ttypa
crw------- 1 root root 3, 11 Nov 7 07:46 /dev/ttypb
crw------- 1 root root 3, 12 Nov 7 07:46 /dev/ttypc
crw------- 1 root root 3, 13 Nov 7 07:46 /dev/ttypd
crw------- 1 root root 3, 14 Nov 7 07:46 /dev/ttype
crw------- 1 root root 3, 15 Nov 7 07:46 /dev/ttypf

[KevinFFF]

Have you tried to use nvidia,tegra194-hsuart instead of nvidia,tegra20-uart for serial@c280000 ?
and you will transfer the data through /dev/ttyTHS2

[Gorgo90]

I changed the drivers to tegra194-hsuart.
I see correctly ttyTHS2:

nvidia@nvidia-orin:~$ sudo dmesg | grep tty
[ 0.000000] Kernel command line: root=PARTUUID=7639c47a-8155-4bc3-83d2-99c160e675c9 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0
[ 0.000805] printk: console [tty0] enabled
[ 0.282297] 31d0000.serial: ttyAMA0 at MMIO 0x31d0000 (irq = 64, base_baud = 0) is a SBSA
[ 3.514414] 3100000.serial: ttyTHS0 at MMIO 0x3100000 (irq = 17, base_baud = 0) is a TEGRA_UART
[ 3.516044] c280000.serial: ttyTHS2 at MMIO 0xc280000 (irq = 61, base_baud = 0) is a TEGRA_UART
[ 3.516696] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 62, base_baud = 0) is a TEGRA_UART
[ 3.517351] 3140000.serial: ttyTHS4 at MMIO 0x3140000 (irq = 63, base_baud = 0) is a TEGRA_UART
[ 4.716812] systemd[1]: Created slice system-serial\x2dgetty.slice.

I retried the loopack test:

nvidia@nvidia-orin:~$ sudo su
root@nvidia-orin:/home/nvidia# stty -F /dev/ttyTHS2 115200 raw -echo
root@nvidia-orin:/home/nvidia# cat /dev/ttyTHS2 &
[1] 2380
root@nvidia-orin:/home/nvidia# echo “test” > /dev/ttyTHS2

But I don’t see any output.

I retried with the Serial/USB to my host, but in this case both TX and RX are not showing anything. I retried the same echo/minicom commands from both sides and viceversa.
With nvidia,tegra20-uartI could see data from ORIN to HOST. With tegra194-hsuart I don’t see any output.

Something is missing?
Thank you for your help

[KevinFFF]

@Gorgo90

I’ve just tried to verify the UART loopback (Wiring TXD/RXD together) with the following commands:

nvidia@nvidia-orin:~$ sudo su
root@nvidia-orin:/home/nvidia# stty -F /dev/ttyS2 115200 raw -echo
root@nvidia-orin:/home/nvidia# cat /dev/ttyS2 &
[1] 3348
root@nvidia-orin:/home/nvidia# echo “test” > /dev/ttyS2

I don’t see any output, confirming that RXD is not working somehow.

When you are verifying with /dev/ttyS2, do you check if there’s any waveform output from TX in loopback test?

@Gorgo90

I disabled nvgetty service

Do you run the following 2 commands to disable getty service?

$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service

[Gorgo90]

@KevinFFF

When you are verifying with /dev/ttyS2, do you check if there’s any waveform output from TX in loopback test?

Yes, I checked with a digital analyzer:

You can see how TX is correctly working while RX voltage doesn’t go to 2V.

@KevinFFF

Do you run the following 2 commands to disable getty service?

$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service

Yes I used those commands:

nvidia@nvidia-orin-rt:~$ sudo systemctl status nvgetty.service
[sudo] password for nvidia:
● nvgetty.service - UART on ttyTHS0
Loaded: loaded (/etc/systemd/system/nvgetty.service; disabled; vendor preset: enabled)
Active: inactive (dead)

[KevinFFF]

@Gorgo90

You can see how TX is correctly working while RX voltage doesn’t go to 2V.

Channel 7 → TX ?
Channel 5 → RX ?

Why your signal is 2V rather than 3.3V?
Are you shorting TX/RX for loopback test now?
If so, you should get the same signal for TX and RX.
It seems the issue coming from no signal on RX rather than Orin NX not recognize the data.