UART2 configuration doubts on TX2 based custom board.

Hello all,

In my nvidia jetson TX2 based custom board, I have a second serial device which uses the UART1 named ttyS2 since I modified the following /hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-common.dtsi:

serial@c280000 {
		compatible = "nvidia,tegra20-uart";
		//compatible = "nvidia,tegra186-hsuart";
		status = "okay";

This I thought necessary since I would like to have serial port communication between my test laptop and the custom board.
The test scenario would be sending an echo command such as, for example, echo -ne ‘\033[2J’ > /dev/ttyS2 --> from my custom board
and receive the ‘\033[2J’ data on my test laptop throught: cat /dev/ttyUSB0 --> from my test laptop

When doing the test I verify that there is data on the serial device pin but there is no data on the cat command.

How to configure the UART1 on device tree on kernel and/or u-boot to have this serial communication working?

I have seen that doing the tegra-quill-common.dtsi modification, as showed above, is not enough to have the UART1 serial working correct?

I really appreciate your help on it!

Thanks in advance and best regards,


Using tegra20-uart instead of tegra186-hsuart should be fine for changing from a “ttyTHS#” to a “ttyS#” if the port is compatible with the tegra20-uart. It sounds like you received part of the communications, but not all of it. Be sure that both ports are set correctly with respect to flow control. If for example one port is expecting CTS/RTS hardware flow control, and the other side is not, then communications will work in one direction, but not in the other.

A useful test is to use loopback. No port will ever disagree with itself about its settings. So if you connect the TX to RX of a port (rather than to another computer), then send and receive should either work or fail. If it fails, and then you loopback the CTS and RTS, and suddenly it starts working, then it indicates flow control was in the way.

You can try loopback first on host, and then on Jetson (each side should be tested to see if that side works in loopback). Make sure first that both work in loopback with the same settings. After this, once the two are cross connected to each other (direct connection implies it is a cross over…TX to RX, CTS to DTS), then it should work if the same settings are used on both ends (even if you know flow control is correct you must still be sure both sides use the same speed, parity, stop bits, so on).

I do not know if your particular device tree serial port address is correct or not. Someone else may be able to answer that, but first I’d try loopback.