how to change uart1(tegra signal ) to drive to uart 2 module pin instead of to uart 0 module pin in tx2/i

presently im getting uart prints from j21 header (uart 0 module pinout) which is connected to uart1 (tx2 tegara signal). from OEM design doc, its debug

serial console is present on j17 header (uart 1 module pinout ) which is connected to uart3(tx2 tegra signal). from OEM design doc , its serial console but im not getting any prints from j17 header.

how to make uart work on serial console port ( j17 header )??

in my custom carrier board i want uart prints on M 2 key connector ( uart 2 module pinout) connected from uart 2 (tegra function) , how can i make changes in SW to drive uart prints from uart1 or uart 3 ( tegra functions ) to uart 2 (module pin) ??

thank you

hello shrinathchoudhary,

you may also refer to similar discussion threads for enable J17 serial console connections, such as Topic 1058564, and Topic 1049045.
thanks

no answer found in those links, Please let me know how to enable j17 !!

can we modify in Software so that whatever signals module giving out from uart1 can be diverted to give out signals from uart2(tegra signal ) to uart2 (pin out)??

This is out of date relative to recent releases, and also is not for a custom carrier board, but you might find this useful:
https://devtalk.nvidia.com/default/topic/1025894/jetson-tx2/uart1-acts-as-default-debug-port-on-tx2-r28-1/post/5220368/#5220368

A point to remember when changing serial port for serial console: The U-Boot software includes only the basic serial UART driver, while Linux can use either that driver or the DMA-capable “high speed” driver provided by NVIDIA. When the UART is accessed by the regular driver it will use the standard naming “/dev/ttyS0” (or other number), but while using the “hsuart” driver (high speed UART), the naming will change to “/dev/ttyTHS0” (or other number). Both of those example devices refer to the same hardware, but the driver used for access requires alternate names. Whichever port you place the serial console on you want to use the “ttyS0” syntax, but for other ports you probably want to use the “ttyTHS0” syntax. Don’t use both simultaneously.

In the device tree you can set ports to “compatible” for more than one UART, this is harmless. However, you could change the device tree to exclude the regular “uart” driver or exclude the “hsuart” driver if you don’t need one. You’ll see the example in that URL. You will need to make adjustments depending on release (just to emphasize, that URL is from an older release).

NOTE: The device tree “serial@” is the base address of the controller. You’ll need to know which controller physical address corresponds to your pin numbers.

Hi,

Whichever port you place the serial console on you want to use the "ttyS0" syntax, but for other ports you probably want to use the "ttyTHS0" syntax. Don't use both simultaneously.

Can you please elaborate ?? I want to test loopback for j17 on tx2 devkit rel 28.2.1

Some explanation here:
https://devtalk.nvidia.com/default/topic/1066498/jetson-tx2/tx2-serialport-uart1-on-j21-40-pin-exp-header-/post/5401918/#5401918

What it comes down to is that the operating system has to pick a driver. Many hardware devices have more than one driver possible, but only one can be used at a time. The “ttyS#” device special files are the result when using one driver, the “ttyTHS#” named device special files use a different driver. You can use either (in the device tree there is a “compatible” line with a comma delimited list of drivers allowed to run the device…remove the “hsuart”…“high speed UART”…and the NVIDIA-provided “ttyTHS#” syntax will disappear). In some cases, if a driver is available in the bootloader, but the other driver is not, then you could use the one driver in U-Boot, but then switch after booting. Or you might want continuity of service when transitioning from U-Boot to Linux, and be forced to retain the legacy driver (during change of driver there will be a momentary loss of function of the hardware). Serial console cares about this, but there are many other hardware drivers not used during boot.