SK-AM62-LP: PRU usage on AM625 SoC

Hello Joerg,

Can you please post a screenshot so I can see what you see in the CCS debug view after the target configuration loads?

It looks like CCSv12.7 is the latest version of CCS that has been tested with the AM62x. I am not sure whether that would make a difference or not:
https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/10_00_00_14/exports/docs/api_guide_am62x/CCS_SETUP_PAGE.html 

M4F does not support initializing PRU cores. 

The other easy way to initialize the PRU clocks that I am aware of is to boot Linux, as documented in the second part of that lab:
https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/latest/exports/docs/common/PRU-ICSS/PRU-Getting-Started-Labs_Lab4.html#initializing-the-pru-from-linux-core

Regards,

Nick

Hello Nick,

thanks for your fast reply. Hier are some screenshots form CCS.  

This error occurs if I try to connect to PUR_ICSS_PRU_0

Another question.

We are planning to use the PRU to get sample values from four ADCs (ADS131M04) with 16000 samples per second.

One idea is to use the M4F for further processing of the sample values. Is it possible to exchange  data between the PRU and the M4F core?

Thanks  for help

Joerg

Hi Nick,

I have tried to start the PRU from Linux. I was able to load my Firmware (PRU_test1.out) to the linux file system.

root@am62xx-lp-evm:~# ls /lib/firmware/pru

PRU_Halt.out  PRU_RPMsg_Echo_Interrupt0.out  PRU_RPMsg_Echo_Interrupt1.out  PRU_test1.out

root@am62xx-lp-evm:~#

After that I execute the grep commands with following results

root@am62xx-lp-evm:~# grep -Isr pru /sys/kernel/debug/remoteproc/

root@am62xx-lp-evm:~#

root@am62xx-lp-evm:~# grep -Isr rtu /sys/kernel/debug/remoteproc/

/sys/kernel/debug/remoteproc/remoteproc1/carveout_memories:     Virtual address: 000000001e6b6679

/sys/kernel/debug/remoteproc/remoteproc1/carveout_memories:     Virtual address: 00000000333f6be0

/sys/kernel/debug/remoteproc/remoteproc0/carveout_memories:     Virtual address: 00000000b7486fff

/sys/kernel/debug/remoteproc/remoteproc0/carveout_memories:     Virtual address: 00000000a47ce9e9

root@am62xx-lp-evm:~#

root@am62xx-lp-evm:~# grep -Isr txpru /sys/kernel/debug/remoteproc/

root@am62xx-lp-evm:~#

The next step fails

root@am62xx-lp-evm:~# echo 'pru/PRU_test1.out' > /sys/class/remoteproc/remoteproc1/firmware

-sh: echo: write error: Device or resource busy

[ 6748.125824] platform 78000000.r5f: can't change firmware while running

root@am62xx-lp-evm:~#

root@am62xx-lp-evm:~#

I did some investigation.

root@am62xx-lp-evm:~# cat /sys/class/remoteproc/remoteproc0/state

running

root@am62xx-lp-evm:~# cat /sys/class/remoteproc/remoteproc0/firmware

am62-mcu-m4f0_0-fw

root@am62xx-lp-evm:~#

It looks that remoteproc0 is used to run something on the M4F core.

root@am62xx-lp-evm:~#

root@am62xx-lp-evm:~# cat /sys/class/remoteproc/remoteproc1/state

attached

root@am62xx-lp-evm:~# cat /sys/class/remoteproc/remoteproc1/firmware

unknown

root@am62xx-lp-evm:~#

 remoteproc1 seems to be attached to something unknown.

 Thanks  for help

Joerg

Hello Joerg,

Connecting through CCS

Ahh, ok. DMSC core is on AM64x, but not AM62x. I need to update the Getting Started Labs.

Could I get you to try connecting to the MAIN R5F core and see if a script runs?

Keep in mind that those Getting Started Lab steps assume you have followed the EVM setup steps in the MCU+ SDK docs:
https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/10_00_00_14/exports/docs/api_guide_am62x/EVM_SETUP_PAGE.html#EVM_FLASH_SOC_INIT

Connecting through Linux 

Hmm... grep -Isr was my attempt to be fancy, but it looks like the command is behaving differently than I expect. Your output is telling you that remoteproc1 is the device management (DM) R5F, and remoteproc0 is m4f.

Please try this command instead to identify which remoteprocX instance is associated with which core:

# head /sys/class/remoteproc/remoteproc*/name

Note that this remoteprocX mapping is NOT fixed - each boot, it can change. So if you are planning to use any runtime scripts, they'll want to initialize remoteproc instances based on the name value, NOT on the remoteprocX number.

Using M4F with PRU? 

TI does not support inter-processor communication (IPC) between the PRU core and the M4F core, or the DM R5F core, on the AM62x. We only support Linux on the A53 cores initializing the PRU subsystem and communicating with the PRU subsystem.

On the AM64x, we do support the R5F cores initializing & communicating with the PRU cores, as well as Linux. So that could be another option for your design if you need more real-time processing capability, and don't need quad core A53 and some of the other AM62x features.

Regards,

Nick

Hello Nick,

Connecting through CCS

I was able to connect and disconnect the MAIN_Cortex_R5_0_0, but it is sill not possible to connect CCS to the PRU core (same Error message as before).

Connecting through Linux 

root@am62xx-lp-evm:~# head /sys/class/remoteproc/remoteproc*/name

==> /sys/class/remoteproc/remoteproc0/name <==

5000000.m4fss

==> /sys/class/remoteproc/remoteproc1/name <==

78000000.r5f

It seems that  on Linux running on my EVM is no remoteproc for the PRUs available.

Using AM64x instead  of AM62x 

We will discuss this in our developer team.

 Best Regards,

Joerg

Hello Joerg,

Ok, let's pause for a minute. It sounds like you are using the LP version of the AM62x SK? That version of silicon does not have a PRU subsystem on it. We actually disable the PRU subsystem in the Linux devicetree file for that board.

arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts

/*
 * All SoC variants with the AMC package have no PRU.
 * Attempting to access the PRU on these devices will
 * result in a crash at kernel bootup.
 *
 * For now, we do not have any code that can figure out
 * the absence of the PRU by reading any SoC registers,
 * so for now disable the PRU here in the board DTS file.
 */
&pruss {
        status = "disabled";
};

If you want to do PRU development, you'll want to use the other AM62x package (which can be found on the "regular" AM62x starter kit EVM)

Regards,

Nick

Hello Nick,

I did some test with another EVM (SK-62B-P1) and it looks much better. Connection via CCS works and I was able to debug my test program. Also the remoteprocs for the PRUs in linux are available. Thank you for your help, but one last question.  We want to evaluate the interoperation between PRUs and the R5F cores on an AM64x SoC. We will order an EVM for AM64 (SK-AM64B). Is this EVM suitable for our test?

Thanks and best Regards

Joerg

Hello Joerg,

Glad to hear you are able to make progress! Apologies that it took a couple of days for me to notice which EVM you were using.

Any feedback for the getting started labs? 

We will be refreshing the getting started labs sometime in the next 6ish months. Did you notice anything "off" that we should fix in the next revision?

AM64x EVMs for testing PRU 

It looks like SK-AM64B has a PRU header that pins out almost all of the PRU GPI / PRU GPO signals, so it should be a pretty easy development platform. The User's guide specifically calls out the header as offering "low speed" connections to the PRU interface. I am not sure what constitutes "low speed", but I will ask around to see if I can get some guidance.

Regards,

Nick