Tegra Combined UART and the tcu_muxer Utility

The Tegra Combined UART (TCU) is a system that multiplexes debug information from the processors in the CCPLEX cluster with information from other processors. The multiplexing is accomplished in the Sensor Processing Engine (SPE), but involves all of the processors that supply information.
tcu_muxer is a utility which runs on a host system and demultiplexes the debug information multiplexed by the TCU.
This diagram shows the relationship of the components for a native (non-virtualized) target.
On a virtualized target, the Virtualized Debug UART multiplexes debug information from the VMs in the CCPLEX cluster and passes the multiplexed data stream to the TCU. The TCU multiplexes it with debug information from the other R5 components. On the host, the CCPLEX debug information customarily is passed from tcu_muxer to uart_muxer, which demultiplexes the individual VMs’ debug information.
This diagram shows the relationship of the components in a virtualized system.

Using tcu_muxer

The tcu_muxer binary is in this sdk directory:
<top>/drive-t186ref-foundation/tools/host/tcu_muxer/
Enter this command to run it:
./tcu_muxer <options>
Where <options> represents any meaningful combination of the command line options described below.
tcu_muxer writes demultiplexed output to a set of consoles with device names in the form /dev/pts/<n>, where <n> is an integer. It lists the consoles’ device names and the type of output written to each on stdout.
It is customary to display each console output data stream with an instance of a terminal utility like minicom. If the target is virtualized, tcu_muxer can demultiplex the CCPLEX processors’ data streams, as in Example 1 below.tcu_muxer initially identifies the CCPLEX data streams by their CCPLEX processor numbers, then again by their VM names. To get just the VM names you must let tcu_muxer CCPLEX data to a single un-demultiplexed output stream and use uart_muxer to demultiplex that stream, as in Example 2 below.
Command Line Options
This table describes the command line options recognized by tcu_muxer:
Command line option
Meaning
-h
Prints a help message summarizing command format and options.
-i
Disables the patch for line ending. This allows some data streams to end lines with <lf> (Linux style) and others to end lines with <cr><lf> (Windows style).
Disabling the patch impairs the usability of the tcu_muxer output, and so is not recommended.
-u
Writes the CCPLEX data to a single output stream, to be demultiplexed by uart_muxer.
-g <consoles>
Applies to: virtualized targets only
Spawns the specified number of consoles for VMs in the CCPLEX cluster. Defaults to 1.
-d <dev>
Specifies the device name of the host UART that receives debug data from the target. Defaults to /dev/ttyUSB3.
-r <rate>
Specifies data rate of the UART in bits/second. Defaults to 115200.
-b <console>
Applies to: virtualized targets only
Sends CCPLEX Hypervisor debug information only to the specified CCPLEX output data stream. For example, ‑b 3 makes tcu_muxer send Hypervisor debug information only to CCPLEX: 3. If ‑b is not used, tcu_muxer sends Hypervisor debug information to all of the CCPLEX output data streams.
-s <path>
Saves output streams to the directory specified by <path>. Each output stream is written to a .txt file whose name represents the source: SCE.txt, SPE.txt, etc. CCPLEX output is written to a single multiplexed file named CCPLEX.txt.
-l <path>
Save the raw output with tags to the log file in the directory specified by <path>.

Examples

Use these examples as models for writing your own tcu_muxer commands.
Example 1: To run tcu_muxer on a virtualized system for X1
$ cd <TOP>/drive-t186ref-foundation/tools/host/tcu_muxer/
$ ./tcu_muxer -g 12 -b 11 -d /dev/ttyUSB2 &
Example 2: To run tcu_muxer on a virtualized system for X2
$ cd <TOP>/drive-t186ref-foundation/tools/host/tcu_muxer/
$ ./tcu_muxer -g 12 -b 11 -d /dev/ttyUSB6 &
 
Output of Example 1
 
/dev/pts/26 RCE
/dev/pts/27 BPMP
/dev/pts/28 SCE
/dev/pts/29 SPE
/dev/pts/30 TZ
/dev/pts/31 CCPLEX: 0
/dev/pts/32 CCPLEX: 1
/dev/pts/33 CCPLEX: 2
/dev/pts/34 CCPLEX: 3
/dev/pts/35 CCPLEX: 4
/dev/pts/36 CCPLEX: 5
/dev/pts/37 CCPLEX: 6
/dev/pts/38 CCPLEX: 7
/dev/pts/39 CCPLEX: 8
/dev/pts/40 CCPLEX: 9
/dev/pts/41 CCPLEX: 10
/dev/pts/42 CCPLEX: 11
################################# 001 ##
/dev/pts/31 [Guest OS]
/dev/pts/33 [Update service]
/dev/pts/32 [Safety service]
/dev/pts/34 [BPMP Server]
/dev/pts/35 [Resource Manager Server]
/dev/pts/36 [System Manager Server]
/dev/pts/37 [Storage Server]
/dev/pts/38 [Security Engine Server]
/dev/pts/39 [Debug Server]
/dev/pts/40 [TrustZone Server]
/dev/pts/42 [Hypervisor]

Using along with uart_muxer Tool

Note:
Usage deprecated.
The uart_muxer tool was originally developed to mux/demux UART streams from virtual machines. The functionality of uart_muxer is now integrated into tcu_muxer. There are still a few subtle differences in the features provided by tcu_muxer and uart_muxer tools. To maintain the interface provided uart_muxer, it is possible to run tcu_muxer and uart_muxer in cascade. In this configuration tcu_muxer is responsible for mux/demux of uart streams from different clusters. tcu_muxer forwards the CCPLEX UART stream to uart_muxer, which muxes/demuxes UART streams from different virtual machines.
Usage
tcu_muxer -u -d <device>
Open uart_muxer on the CCPLEX ports:
<TOP>/hypervisor/tools/uart_muxer/uart_muxer -g <guest_nr> -b <hyp_nr> -d <device>
Where
<guest_nr> represents the number of virtual machines.
<hyp_nr> represents the pseudo terminal for hypervisor.
Example
$ tcu_muxer -u -d /dev/ttyUSB2
/dev/pts/38 RCE
/dev/pts/84 BPMP
/dev/pts/91 SCE
/dev/pts/95 SPE
/dev/pts/103 TZ
/dev/pts/104 CCPLEX: 0
 
# <TOP>/hypervisor/tools/uart_muxer/uart_muxer -g 9 -b 8 -d /dev/pts/104
################################# 001 ##
/dev/pts/106 [Guest 0]
/dev/pts/107 [BPMP]
/dev/pts/115 [Resource Manager]
/dev/pts/116 [Monitor Partition]
/dev/pts/118 [I2C]
/dev/pts/122 [System Manager]
/dev/pts/128 [Storage]
/dev/pts/131 [Security Engine]
/dev/pts/132 [Hypervisor]
 

Finding the Number of VM Partitions

tcu_muxer takes the number of terminals to launch as an input parameter, -g. The required number of terminals depends on the number of virtual machines/partitions present in a given virtualized system configuration.
The tool pctdump can get this information by reading the configuration blob.
Usage
pctdump <pct configuration blob>
Here is an example (for E3550 T194 Hypervisor Linux Configuration):
$ <TOP>/virtualization/tools/t18x/pctdump_x86/pctdump <TOP>/virtualization/hypervisor/t19x/configs/t194ref-release/pct/linux-linux/pct.bin
Guest Names
[0] Guest 0
[1] BPMP
[2] Resource Manager
[3] Monitor Partition
[4] System Manager
[5] Storage
[6] Security Engine
 
To the total of 7 VMs, add 2 VMs for internal debug and TZ server and 1 VM for Hypervisor. The final count is 10, and the tcu_muxer command is:
$ tcu_muxer -g 10 -b 9 -d /dev/ttyUSB2