Repurpose Debug UART for 'normal' comms on Xavier NX

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

Hi,

we have been experimenting for a while, with various devicetree and config changes - to make use of the third UART on the Xavier NX.

Ideally we want to add an additional serial peripheral (a STM32 microcontroller) on this port, and do reliable bidirectional comms with it. We have LIDAR and other seral

This, by default, uses the ‘combined’ or tcu driver - and appears as /dev/ttyTCU0

By default, on startup, there is a lot of logging output sent to this port, as far as we can tell by the BPMP.

Once the system is running, it is possible to use /dev/ttyTCU0, but it has unwanted line-ending behaviour, as well as observing strange ‘replace 0xFF with 0xFF0xFF’ behaviour when sending bytes via this port. A look at the driver source e.g.

shows this clearly, and these translations make it quite unsuitable for a ‘raw’ serial device.

So, we attempted to disable the combined uart driver, and enable the ‘normal’ serial driver for this port - as far as we can tell, successfully - with our devicetree modifications we were able to bring up a /dev/ttyTHS2 - but loopback connections stall after a few bytes, and bidirectional comms (e.g. between minicom running on the Xavier NX and a laptop - do not work as expected at all, it seems like output is lost, and buffered in strange ways:

e.g. data will only be passed sent from the jetson on the tx, when a byte is received on its rx, and frequently, where data is sent from the laptop, it is lost - e.g. a sequence of typed digits ‘123456789’ might be received as ‘1235689’ or similar.

This makes /dev/ttyTHS2 unusable for our purposes too.

Possibly, what we are seeing is some side effect from peripherals like the BPMP, or others, ‘sharing’ the debug connection, even when the combined driver is not loaded, but whatever the issue is, it is very confusing.

There are numerous posts in these forums, which detail, as far as I can see - only partial success in being able to use UART3 as a ‘clean’ UART, with references to a multitude of postings, none of which ever seem to end in confirmed success doing this.

So I would like to ask the following:

Is it possible to completely disable the use of this UART, other than from user-space after the kernel is booted? e.g. when powering up the Jetson Xavier NX - no output whatsover should appear on this uart, from any peripheral.

Once the kernel is booted - is it possible to send and receive data on this uart reliably via the tegra highspeed uart driver, as if was a standard port behaving the same way as the ttyTHS1 device?

If the answer to the above two questions is yes, what is a clear set of steps to acheive this - following some of the advice in the other threads, specifically setting the BPMP uart to Oxff instead of 0x03 - seems to stop the NX from booting up at all, for example, and it is very hard to know how to proceed.

Thanks

-Pete

3

hello pete28,

you may refer to this thread disable Xavier NX combined uart, Topic 182785

4

Hi Jerry,

yes, this is broadly the process we followed, and the files that were touched in attempting this - however - you never state what to change in the 5 files you mention, and explicitly say in the previous message on that posting that this failed for you and is under internal investigation.

Perhaps, the answer to a specific question will bring enlightenment to me on this - after decompiling the BPMP .dtb, ( tegra194-mb1-bct-misc-l4t.cfg )I changed some of the mb2 feature flags to disable its use of the uart.

I set ‘enable_combined_uart = 0;’
and ‘spe_uart_instance = 0xff;’

And the board does not boot when the recompiled dtb is flashed.

What do i need to change in this file so the device boots, and the combined uart is disabled?

Thanks,

-Pete

1 Like
5

I also note that you didn’t even try to answer the questions I asked - following a series of one-line answers pointing me to other message board postings is what has got me this far, but I have yet to read a confirmation that anyone has got ‘clean uart’ behaviour out of the debug uart on Xavier NX.

So, for clarity:

Is it possible to completely disable the use of this UART, other than from user-space after the kernel is booted? e.g. when powering up the Jetson Xavier NX - no output whatsover should appear on this uart, from any peripheral.

Once the kernel is booted - is it possible to send and receive data on this uart reliably via the tegra highspeed uart driver, as if was a standard port behaving the same way as the ttyTHS1 device?

1 Like
6

hello pete28 ,

sorry, I realize that I should point-out this thread, Topic 160948.

the uart log on Xavier series is Tegra Combined UART, which means the uart log from CCPLEX and also BPMP can be seen in the default UART.

so,
please try below steps to disable TCU.

  1. modify mb1-bct.
  enable_combined_uart = 0;
  spe_uart_instance = 0xff;  // for UARTC: it was 0x2
  1. modify kernel device tree, to load uart8250 driver and update the bootargs.
  serial@c280000 {
       compatible = "nvidia,tegra20-uart"; // To load uart8250 driver
       status = "okay";
    };
  chosen {
       bootargs = "console=ttyS2,115200 earlycon=uart8250,mmio32,0x0c280000";
  };
  1. you may disassembler the bpmp-dtb, changes the content as following,
  -#include "parts/policy/serial-3-comb-uart.dtsi"
  +#include "parts/policy/serial-2-input.dtsi"

 / {
        serial {
-               port = <3>;
+               port = <2>;
                has_input;
-               combined-uart {
-                       enabled;
-               };
        };

 };
  1. update flash configure file, here’s an example to change from TCU0 to ttyS2 for UART-C.
  CMDLINE_ADD="console=ttyS2,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4";
7

Thanks Jerry,

thats really useful and the kind of comprehensive answer that might be good to put in a wiki or FAQ…

The biggest difference, between what I currently have and what you have posted above that might account for the strange I/O on the uart when used for data transfer might be the compatible=nvidia,tegra20-uart - is the use of the older tegra20 uart driver a requirement of this hardware port?

My devicetree (minimally modified from what is shipped in Jetpack 5.02) binds the tegra186-uart driver, in line with the disabled definition for the c280000 port that was present in the devicetree that i enabled (set to “okay”) in order to get a /dev/ttyTHS2.

Is the use of tegra20-uart required because these uarts (c280000 and c290000) are different from the ‘primary’ uarts on the xavier nx - looking at the tegra-hsuart driver source code there are differences between the tegra20-uart and later versions, and i see some reference in other forum postings to these ports not supporting the same dma capabilities the tegra186-uart driver would try to use.

Thanks,

-Pete

8

we’ve test that steps to disable combined UART on Xavier NX DevKits, please also check and share your results.

9

As mentioned in the very first message of this thread - I have also been able to successfully disable the combined uart, and to bind the tegra-hsuart driver to the device, but actual data transfer over the port is very unreliable / non-functional - even a loopback jumper cable (tx->rx) fails to echo more than a few sent bytes in a terminal emulator e.g minicom, and host<->host transfers also show strange buffering / missing data problems.

Have you verified correct data transfer in addition to the lack of a /dev/ttyTCU0 and addition of a /dev/ttyS2 or /dev/ttyTHS2? because it seems like it should work - no dmesg errors or similar - and it sort of does work with tegra186-hsuart, but not in a way thats useful for transport of real-world data…

And what my initial questions were trying to resolve is - does this actually work, vs just look like it works - i.e. how much testing, if any - have you done with real world data transfer over the port that results from this process, and assuming there has been some - was any spurious behaviour such as I outlined above - present?

I tried using the ‘tegra20-uart’ driver in place of the ‘tegra186-hsuart’ driver, and got no I/O at all - I tried removing the dma devicetree entries for the tegra186-hsuart devicetree config so that it would be forced into PIO mode to see if dma was complicating things and got no I/O at all.

Looking at the tegra-tcu driver, it seems that it only talks with a mailbox buffer, and the actual uart initialisation and I/O is done by the SPE hardware on the jetson, and
the tcu driver hardcodes line-ending subsitutions/replacements that are not compatible with raw data transfer.

Are the ports on c280000 and c290000 - which, as far as I can tell - are part of the ‘AON - always on?’ hardware block of the SoC, actually drivable by the tegra-serial driver in the kernel - and if so, which variant?

if it is not tegra186-hsuart on the xavier nx, why is there a config for it in the platform devicetree with presumably correct clocks, registers and dma entries?

tegra186-hsuart kind of works - a /dev/ttyTHS2 is present, but cannot correctly transfer data.

using tegra20-uart, as you suggest above, results in a port that can be opened but results in no IO at all on /dev/ttyS2.

My situation is pretty much exactly the same as this person here:

They ended up re-enabling the TCU driver because the tegra-hsuart driver could not correctly drive it.

Really, what i’m looking for is not another redirection to a forum post, but an answer on whether this can work - I dont mind experimenting and following forum posting rabbit holes if I know that this does work and i just need to figure out the configuration to make it work - but if i’m just following forum postings and wasting hours on devicetree changes and reflashing boards - when it actually can’t work.- you know, itd be better to understand that sooner vs later.

1 Like
11

hello pete28,

we have not verify disable combined uart use-case.
please see-also Jetson Xavier NX Product Design Guide for [Figure 12-5. UART Connections].
you may try using other port.

12

Hello Jerry,

This a rather poor answer - i’ve been following this thread and you’ve lead pete along for a few weeks saying that this is possible and only now you are revealing that this may not actually work and your solution is un-tested.

In our case we are using all three uarts on the Xavier and need the uart3 to function as a normal uart with no debug for our carrier PCB to function fully.

Do you have any further suggestions on how to proceed with getting this uart to function correctly.

19

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.