Enable UARTC/UARTG access from CCPLEX

Is it possible to use UARTC (J17 serial) from the main CPU? I am able to use the Tegra IVC protocol to get the BPMP to reset deassert and clock enable all of the other UART devices. However, the UARTC and UARTG which are part of the SPE cluster are still not able to be accessed.

A memory read of the MMIO base for those UARTG is typical for a device that’s still held in reset: 0xdead1009, and UARTC is always 0 which also seems to indicate it’s being held in reset.

How are SPE devices enabled and made accessible to the CCPLEX? (Note that I am working from the TrustZone in place of Trusty pre normal world boot).

I have tried enabling the AON_APB and AXI_CBB through the same BPMP IVC mechanisms, with no differences.

hello richard.habeeb,

UART pinmux configuration is only supported for UART1, UART2 and UART7.
here’re available settings.

UART-A |   DEBUG_UART1  |  uart_instance= 0
UART-B |   UART_UART2   |  uart_instance= 1
UART-G |   AO_UART7     |  uart_instance= 6

So I think I figured out most of my issue there was a tiny bug on my end. It wasn’t related to the pinmux.

I still have some questions about the UART table that you listed. I’ve been confused about the UART naming scheme for awhile, and I’ve gotten some conflicting info from NVIDIA documentation for the TX2. The Parker TRM seems to use the A-G naming scheme, but the OEM guide and the Dev Kit Spec use the numbering scheme and I they don’t seem to be 1-1 mapped. Can you confirm?

You seem to be implying that the mapping is:

UARTA -> UART0
UARTB -> UART1
UARTC -> UART2
...

The Dev Board Spec lists the pins on J17 as UART1, but these pins trigger the interrupt for UARTC.

Furthermore, the OEM guide Table 75 has this mess:

Module Pins (Tegra Functions) | I/O Block       | Typical Usage
------------------------------+-----------------+--------------
UART0 (UART1)                 | DEBUG           | Debug     
UART1 (UART3)                 | AO              | Serial Port 
UART2 (UART2)                 | UART            | M.2 socket for external WLAN / BT 
UART3 (UART4)                 | CONN            | ... 
UART7 (UART7)                 | AO              | 2nd Debug/Misc.

Reading between the lines I think it means that UART0 = UARTA, UART1=UARTC, UART2=UARTB, UART3=UARTD, UART7=UARTG.

This seems to also align with the TRM’s table:

UART1/UARTA
UART2/UARTB
UART3/UARTC
UART4/UARTD
UART5/UARTE
UART6/UARTF
UART7/UARTG

But the fact that there are three naming schemes, one with letters, one with zero-indexed numbers, and one with one-indexed numbers is a source of constant pain for me (especially because they don’t map as you might expect). This doesn’t even get into the Ball names, PADCTRL names, etc. Is there a definitive table or spreadsheet somewhere?

Thanks.

hello richard.habeeb,

sorry for confusion, I’m try to implying Module Pins and the I/O Block for using uart_instance.
please also refer to Miscellaneous Configurations for setting debug.uart_instance.
for example, when configure debug.uart_instance=1; it choose port UART_UART2, to configures the UART instance for console prints.

you should refer to [Figure 46. UART Connections] for the detail mappings of Module Pins and Tegra Functions.
as for UART-A, UART-B, UART-C…it’s better to check device tree for its serial ports.
for example,
$L4T_Sources/r32.6.1/Linux_for_Tegra/source/public/hardware/nvidia/soc/t18x/kernel-dts/tegra186-soc/tegra186-soc-uart.dtsi

uarta: serial@3100000 {...}
uartb: serial@3110000 {...}
uartc: serial@c280000 {...}
...