PRU-SWPKG: PRU access to host memory

Puneeth,

Sorry for the delay, I was away from my desk the last two weeks.

1. Can I use the same method for data communication between PRU and ARM in production?

The decision to use this communication in a production environment is yours to make. Many production systems remove the /dev/mem device from the filesystem as it can read/write the full memory map of the device which can pose a security risk. However, /dev/mem is only available when running as root, so if someone has root access to your fielded system then you most likely have larger security concerns to worry about.

2. We are directly accessing the memory without intimating the kernel, Is this a safe thing to do? What if the kernel allocates this memory to another application?

As shown in the memory mapping response below, the memory that you are using in this case resides in the Data Ram of PRU0 in the PRU-ICSS0. Unless you are using one of our TI provided PRU Ethernet Linux drivers (I don't think that you are) then Linux should not make use of any of the memories inside of the PRU-ICSS.

If you were to choose to share an address in DDR memory (0x8000_0000 or higher) then yes, you would need to let Linux know not to use that memory section for anything else. This can be accomplished with a simple device tree node if necessary but shouldn't be necessary in your current use case.

3. Section 30.3.1.2 Local Data Memory Map of  the Technical Reference Manual says that  PRU can access external host memory from 0x0008_0000 address, However, I can't  access it from from 0x0008_0000. but I can access it at 0x54440FD0. How can I find the address mapping b/w ARM and PRU (so that I can use it in my application)?

In the AM437x device, the GLOBAL starting memory location for the PRU-ICSS is 0x5440_0000 (as shown in the L3 Memory Map from section 2.1.1 at the beginning of the TRM). The offsets shown in Table 30-6 are where the PRU-ICSS's memory appear in the Global Memory Map. Using your 0x54440FD0 address as an example:

   0x5440_0000 (Global Memory Location for start of PRU-ICSS peripheral, from Table 2-1 in the TRM)

+ 0x0004_0000 (Global Memory Map starting offset for PRU-ICSS0 DRAM 0, from Table 30-6 in the TRM)

+ 0x0000_0FD0 (Address offset 0xFD0 at the end of the PRU-ICSS0 DRAM 0)

----------------------------------------------------------------------------------------------------

0x5444_0FD0 (Global Memory Mapped location of PRU-ICSS0 DRAM 0 address 0xFD0)

The ARM core is only capable of accessing memories using the Global Memory Map. So, the 0x5444_0FD0 address is the only way for the ARM core to read or write this location.

The PRU cores however, can use either the global address or a local address (which you and I discussed briefly before https://e2e.ti.com/support/arm/sitara_arm/f/791/p/619957/2287114#2287114). Cores in the same PRU-ICSS use an offset of 0x0000_2000 to reach the other core's DRAM. Cores in different PRU-ICSS's use an offset of 0x0004_0000 to get to the base of the OTHER PRU-ICSS (mentioned in Table 30-5 in the TRM).

Here's a breakdown of the addresses each core can use to access that exact same memory location (which is in PRU-ICSS0 DRAM 0):

ARM Core -> 0x5444_0FD0 (Global Memory Map location)

PRU-ICSS0 PRU0 -> 0x5444_0FD0 (Global Memory Map location *)

PRU-ICSS0 PRU0 -> 0x0000_0FD0 (Local Data Memory Map location (same ICSS, same core's DRAM))

PRU-ICSS0 PRU1 -> 0x5444_0FD0 (Global Memory Map location *)

PRU-ICSS0 PRU1 -> 0x0000_2FD0 (Local Data Memory Map location (same ICSS, different core's DRAM))

PRU-ICSS1 PRU0 -> 0x5444_0FD0 (Global Memory Map location *)

PRU-ICSS1 PRU0 -> 0x0004_0FD0 (Local Data Memory Map location ** (other ICSS))

PRU-ICSS1 PRU1 -> 0x5444_0FD0 (Global Memory Map location *)

PRU-ICSS1 PRU1 -> 0x0004_0FD0 (Local Data Memory Map location ** (other ICSS))

* these global accesses from the perspective of a PRU will exit the PRU-ICSS and be routed on the shared memory bus back into the PRU-ICSS. Hence, these accesses will take longer and be less deterministic than local accesses.

** a silicon bug was found when using the memory bridge between the two PRU-ICSS's on the AM437x device. 4 byte reads and writes accross the bridge will work correctly, however burst reads and writes that are longer than 4 bytes will fail to complete correctly. This e2e post explain more: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/624669/2303523#2303523

Hopefully that will answer your mapping questions.

Jason Reeder