NX2 TX UART on debug console port

[atomic-7]

I have a NX2 TX on a carrier board from seeed studio (A203V2) and would like to use the uart pins on the J40 header to communicate with a flight controller for a drone.
I am aware that the tx2 nx has multiple serial ports, however the carrier board only makes one available on the header so I am stuck with this one.
Per default, a debugger console seems to sit on this port. The instructions found in this post suggest to disable the serial port in the bpmp configuration file.

TX2 NX RS232 Communication Problem

hello mehmetdeniz, we had also test this with TX2 NX, it’s confirmed we’re able to disable BPMP logs. here’re steps for your reference, Enable THS2 with /Linux_for_Tegra/kernel/dtb/tegra186-p3636-0001-p3509-0000-a01.dtb + serial@c280000 { + compatible = "nvidia,tegra186-hsuart"; + status = "okay"; + }; Disable bpmp-dtb port with /Linux_for_Tegra/bootloader/t186ref/tegra186-bpmp-p3636-0001-a00-00.dtb - serial { - port = <3>; - has_input; - }; perform full flash to update these two d…

# Tegra_for_Linux/bootloader/t186ref/tegra186-bpmp-p3636-0001-a00-00.dts
-	serial {
-		port = <3>;
-		has_input;
-	};

Additionally I followed these instructions as well and disabled the debug log in this file:

UART1 acts as default debug port on TX2, R28.1

hello Tonie, could you please check and share the kernel messages. please check whether UART port# has verified or not, thanks dmesg | grep -i THS

# tegra186-mb1-bct-misc-si-l4t.cf
debug.enable_log=0;

The next steps were to remove any references to starting a serial console in the kernel cmdline via p3636.conf.common and the ‘chosen’ node in the dtb for the carrier board.
So far it seems to have worked as there no longer is any output printed during boot and sending commands does not cause any response.
Once the system was running I disabled the nvgetty service, added the user to the dialout group and restarted the system to apply the changes.

At this point however I am stuck. I would expect to be able to send and receive from ttyS0 using picocom with a baudrate of 115200.
After connecting a serial to usb converter to the pins, neither sending nor receiving seem to work.
The output from dmesg | grep tty suggests that ttyS0 is running in PIO mode and the group of the tty is dialout, meaning I should have access to it.

sudo dmesg | grep tty
[    0.000000] Kernel command line: root=PARTUUID=647ac557-cf7c-4c36-bcf1-34caf870ac77 rw rootwait rootfstype=ext4 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2  video=tegrafb nvdumper_reserved=0x1772e0000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0x96085000 lut_mem=0x2008@0x96081000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000 sdhci_tegra.en_boot_part_access=1 quiet root=PARTUUID=647ac557-cf7c-4c36-bcf1-34caf870ac77 rw rootwait rootfstype=ext4 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 
[    0.000924] console [tty0] enabled
[    0.913792] 3100000.serial: ttyS0 at MMIO 0x3100000 (irq = 32, base_baud = 25500000) is a Tegra
[    0.914858] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 33, base_baud = 0) is a TEGRA_UART
[    0.915535] c280000.serial: ttyTHS2 at MMIO 0xc280000 (irq = 34, base_baud = 0) is a TEGRA_UART
[    0.916279] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 35, base_baud = 0) is a TEGRA_UART

ls -l /dev/ttyS*
crw-rw---- 1 root dialout 4, 64 Nov 24 17:23 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 Nov 24 17:23 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Nov 24 17:23 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Nov 24 17:23 /dev/ttyS3

ls -l /dev/ttyT*
crw-rw---- 1 root dialout   4, 143 Nov 24 17:23 /dev/ttyTCU0
crw-rw---- 1 root dialout 238,   1 Nov 24 17:43 /dev/ttyTHS1
crw-rw---- 1 root dialout 238,   2 Nov 24 17:23 /dev/ttyTHS2
crw-rw---- 1 root dialout 238,   3 Nov 24 17:43 /dev/ttyTHS3

I tested the other serial ports as well in case I misunderstood which tty would be available, but neither is responsive. Trying to access the ttys ttyS1, ttyS2 and ttyS3 results in 'FATAL: failed to add device /dev/ttyS1: Filedes is not a tty',
presumably because there are similarly named ttys ttyTHS1, ttyTHS2, ttyTHS3 up with dma already occupying these ports.
I assume they are responsible for the m2 key and the camera module.
Trying to access ttyTCU0 causes the system to hang up and reboot, ttyTHS1, ttyTHS2 and ttyTHS3 all seem unresponsive but at least no crashes.

I have read a plentitude of forum posts regarding this topic but I still find myself lost and would appreciate if you could help me understand where I am going wrong.
If there is any other info I can provide to help please let me know.

[linuxdev]

The fact that all ports are now group dialout is good. It means serial console is not in the way.

Just to find the right port I’ll suggest this experiment (which is using loopback mode): Connect the UART on the Jetson to talk to itself, and then try to use a serial console program to talk to the port…if it echoes back, then you have the right port.

Directly jumper the TX and RX pins. If you use flow control, then also jumper the Jetson’s own CTS to RTS. I use gtkterm, although any serial console program will work for this (if you want gtkterm, then sudo apt-get install gtkterm). Whatever serial console program you use will work. Then connect to each port in turn, e.g., “/dev/ttyS0”, then “ttyS1”, and so on, along with each “ttyTHS”. Mark which ones respond (up to two ports will respond).

FYI, the ttyS# ports use the standard 16550A driver as set up. The same # in ttyS# and ttyTHS# is the same UART, but the THS version is the “Tegra High Speed” driver…it uses DMA to reduce CPU load. Early boot stages don’t have the THS DMA-capable driver, and to get continuity of serial console log messages, usually it is ttyS# used for serial console…but it is the same hardware as the matching ttyTHS# (if you enable serial console logging, then the “group” of one ttyS and one ttyTHS should both become “tty” instead of “dialout”). Thus I recommend checking all ttyS and ttyTHS. Pick one, use only the one.

The ttyTCU started showing up in later Jetson models which had a micro-B USB port (which is still pretty old). This has been from serial console over the USB port. Not sure what the relation will be on your system, but if it is a header pin, then I doubt ttyTCU# is relevant. On the other hand, if your board you are working with has a USB host port, then this is a candidate for serial communications (though I would not recommend using this permanently since it also adds USB to the chain).

[atomic-7]

I figured out the problem.

Before asking this question, I had modified the dtb to activate the serial port (serial@c280000) since it was inactive in the suppliers configuration.
In order to test this change I redid the wiring that connects the pins on the breakout board with the usb2serial connector and incorrectly connected the tx and rx lines.

Doing the loopback setup immediately revealed that the dtb change worked. I initially did not notice that the serial port was not set to okay since the bpmp console was able to access the port, but it seems that bpmp does not need the device tree to find it.
After all the trouble to make it work the last problem was in front of the computer.

For anyone else that tries to use uart1 on the Seeedstudio A203V2, remember to set the serial@c280000 to okay in the dtb that is supplied in addition to the steps outlined in my initial post. The tty that ended up working was /dev/ttyTHS2 and that was only available after the dtb change.

Thank you so much for your fast response and good advice, your posts both here and in other topics have been a huge help.

[linuxdev]

@atomic-7

After all the trouble to make it work the last problem was in front of the computer.

Instead of the above, I prefer to say that “the advanced neural wetware” needed adjustments (versus hardware or firmware or software). :P