AM625: PR0_UART0_TXD and PR0_UART0_RXD can be used as a PRU debug uart?

Hello Meera,

Yes, there is a full hardware UART peripheral within the PRU subsystem. There are several ways that it can be used:

From Linux A53 cores 

Starting in Linux SDK 11.0 (I think; definitely supported in Linux SDK 11.1) the Linux A53 core can control the PRU hardware UART just like any other UART in the system. grep for pruss_uart in arch/arm64/boot/dts/ti

From the PRU cores 

The PRU core can also control the hardware UART. You can find an example of that in the PRU Software Support Package here:
https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am62x/PRU_Hardware_UART

Regards,

Nick

Hi Nick,
          Thank you for your quick response. Can we use these 2 pins  PR0_UART0_TXD and PR0_UART0_RXD as a PRU debug console by changing in the device tree? 

Hello Meera,

Please provide additional information about what you mean by "PRU debug console".

Regards,

Nick

PRU debug console means, as like MCU debug uart can we print debug messages on console of main CPU initiated using printf or something without sending RPMsg to the MPU? 

Hello Meera,

Yes, the PRU can write characters to the UART. You can use that PRU firmware project that I linked in my previous response as a starting point.

You can also use other methods to debug the PRU core during runtime. I am still in the process of porting the PRU Getting Started Labs to the upcoming AM62x PRU Academy. For now, you can find additional tips on debugging the PRU core in Lab 5 of the existing PRU Getting Started Labs:
https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/11_01_05_03/exports/docs/common/PRU-ICSS/PRU-Getting-Started-Labs_Lab5.html

Regards,

Nick

Thank you Nick for your confirmation. To enable PRU_uart, what are the device-tree modifications are required? Will you please help me to do that?

I have added PRU uart driver by adding patch of 8250_pruss.c in the kernel, along with that I have added kernel module CONFIG_SERIAL_8250_PRUSS=m.

After that I have added patch 

diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index b3715472d77c..a17185bc18d6 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -1191,6 +1191,17 @@ pruss_iepclk_mux: iepclk-mux@30 {
 				};
 			};
 		};
+	
+		pruss_uart0: uart@28000 {
+			compatible = "ti,pruss-uart";
+			reg = <0x28000 0x40>;        /* offset 0x28000, size 8KB */
+			interrupt-parent = <&pruss_intc>;
+			interrupts = <6 4 4>;        /* event 20, channel 1, host 0 (per TI) */
+			clocks = <&k3_clks 81 13>;     /* pruss_core_clk */
+			clock-names = "fck";
+			status = "disabled";
+		};
+			
 
 		pruss_intc: interrupt-controller@20000 {
 			compatible = "ti,pruss-intc";
diff --git a/arch/arm64/boot/dts/ti/k3-am625-osd625-brk.dts b/arch/arm64/boot/dts/ti/k3-am625-osd625-brk.dts
index 16da1b3fe308..26f400d69f17 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-osd625-brk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-osd625-brk.dts
@@ -28,6 +28,7 @@ opp-1400000000 {
 	aliases {
 		serial2 = &main_uart0;
 		serial3 = &main_uart1;
+		serial4 = &pruss_uart0;
 		mmc1 = &sdhci1;
 		usb0 = &usb0;
 		usb1 = &usb1;
@@ -287,6 +288,14 @@ AM62X_IOPAD(0x0198, PIN_OUTPUT, 2) /*MCASP0_AXR2  -> UART1_RTSn */
 		>;
 	};
 
+	pruss_uart_pins: pruss-uart-pins {
+		pinctrl-single,pins = <
+			AM62X_IOPAD(0x01d8, PIN_INPUT, 6) /* (C15) MCAN0_TX.PR0_UART0_RXD */
+			AM62X_IOPAD(0x01dc, PIN_OUTPUT, 6) /* (E15) MCAN0_RX.PR0_UART0_TXD */
+		>;
+	};
+		
+
 	mikrobus0_uart_pins_default: mikrobus0-uart-default-pins {
 		pinctrl-single,pins = <
 			AM62X_IOPAD(0x01f8, PIN_INPUT, 1) /* MMC0_DAT7.UART2_RXD */
@@ -381,6 +390,12 @@ &main_uart1 {
 	status = "okay";
 };
 
+&pruss_uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pruss_uart_pins>;
+	status = "okay";
+};
+
 &main_gpio0 {
 	bootph-all;
 };

root@osd62-pm-brk:~# dmesg | grep uart
[    7.776514] 30068000.uart: ttyS4 at MMIO 0x30068000 (irq = 465, base_baud = 20833333) is a 16550A

Hello Meera,

Apologies for the delay. I am glad to hear that you are able to make progress.

What version of the Linux kernel are you using?

I would expect that if you are using Linux kernel 5.10 or later (I do not think AM62x is supported on any earlier Linux kernel versions), then you only need to add a resource table if you are using RPMsg to communicate between Linux and the PRU core.

What are you trying to accomplish in your design? 

Linux controlling the PRU hardware UART

We added support for Linux controlling the PRU hardware UART on AM62x in Linux SDK 11.0, I believe (Linux kernel 6.12). You can find more information by searching for "pruss_uart" in the dts files under arch/arm64/boot/dts/ti:
k3-am62-main.dtsi
k3-am62x-sk-common.dtsi

Note that Linux controlling the PRU HW UART does NOT require loading any firmware into the PRU cores. Linux just applies power to the PRU subsystem, and starts directly reading and writing to the PRU HW UART registers.

PRU core controlling the PRU hardware UART 

If you want the PRU core to send and receive data to the PRU HW UART instead of Linux sending and receiving data to the PRU HW UART, then you can use the PRU_Hardware_UART project as a starting point.

Regards,

Nick

One additional note on the resource table question:

for more information about when PRU resource tables are actually needed in TI Linux SDKs, refer to 
https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/11_01_05_03/exports/docs/common/PRU-ICSS/Resource_Tables.html

If you are using a non-TI branch of the Linux kernel, I am not sure whether you would have all the same PRU remoteproc driver commits as the driver in the official TI branches, ti-linux-kernel-X.X.y. So if you are using a non-TI kernel branch, perhaps a resource table is still required for loading any PRU firmware.

Note that all the other non-Linux cores DO require a resource table in order to be loaded by the Linux remoteproc driver (on AM62x, that means the M4F core).

Regards,

Nick