Replacing Debug serial with normal UART

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.

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

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

截圖 2023-04-25 上午8.47.35

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.

image

  • 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!

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

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

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!

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.

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

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

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?

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.

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 :)

Thanks for your clarification.

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.

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

  1. Added the user to dialout

  2. 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”;

  1. I disabled nvgetty service
  2. 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.

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

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

Is it ok?

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.

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*

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

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

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

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

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

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

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

Yes, I checked with a digital analyzer:


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

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)

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.

Correct.

Good question. I wonder why, but at least it’s more than 1V and closer to 3.3V.
I checked with the analyzer and ttyTHS0 TX (uarta@3100000 (serial0)) is actually 3.2V.

No, sorry, I could explain myself better. I wired TX and RX to the digital analyzer and I saw the RX (channel 5) was actually ~0V. Is ti correct 0V?
I only tried to send data from TX as you can see in the image.

Here a loopback test where I analyze the transmission between TX and RX on ttyS2:

As commands I did:

root@nvidia-orin-rt:/home/nvidia# stty -F /dev/ttyS2 -opost -onlcr -isig -icanon -iexten -echo
root@nvidia-orin-rt:/home/nvidia# socat - /dev/ttyS2,raw,echo=0
test