AM625: Access PRU from M4 MCU

Hello Tony,

The M4F can use the RAT to translate system addresses into the local address space that M4F can access. I am still working on this document (getting added to the Linux Academy soon), but here is the draft:

Updating the Region-based Address Translation (RAT) Settings
------------------------------------------------------------

The R5F, PRU_ICSSG/PRU-ICSS/PRU-SS, and M4F remote cores all have
region-based address translation (RAT) modules. M4 cores are most likely
to need to configure the RAT. However, be aware that the R5F and PRU cores
also have RAT functionality.

When do the RAT settings need to be changed?
""""""""""""""""""""""""""""""""""""""""""""

The RAT settings in TI’s example projects can be used as a starting point.
However, the example projects may have different address mappings than
your use case.

Address translation is needed in these usecases:

* The core must access memory beyond a 32-bit address space (For example,
the on-chip debug hardware configuration registers have addresses larger
than 0xFFFF_FFFF).

* The core must access memory regions that are not accessible from its local
addresses.

Memory regions may not be accessible because:

* The memory region is already defined for local resources (for example,
M4F has local resources at addresses that are less than 0x6000_0000, and
greater than 0xDFFF_FFFF).

* The project has already remapped a different memory space over that
local address (for example, if system address 0x0000_0000 is remapped
to local address 0x8000_0000, and the core needs to access system
address 0x8000_0000, then system address 0x8000_0000 must be remapped
to a different local address)

For M4F in particular on AM24x/62x/64x, check the RAT settings when the M4F
project accesses:

* System memory and external memory (for example, in a shared memory usecase)

* Device configuration registers (pinmux, clocking, power, reset, etc.
Reference TRM chapter “Device Configuration”)

* Main domain resources (note that M4F drivers only support using MCU domain
peripherals by default. Reference the MCU+ SDK Release Notes for a list of
supported peripherals)

.. TODO: Is the above note about default driver support accurate?

How to update the RAT Settings in the Remote Core Project
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""

RAT mappings for MCU+ projects are stored in the SysConfig file example.syscfg.
example.syscfg can be edited with the SysConfig tool, or directly with a file
editor.

TODO: example with images for modifying using the SysConfig tool

TODO: the same example, but modifying the example.syscfg file.

How to use RAT Translation within the Remote Core Firmware
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

MCU+ functions distinguish which peripheral they are talking to by passing the
base address of the peripheral in the function call.

All software written with the MCU+ SDK should use AddrTranslateP_getLocalAddr
to get the local address of the peripheral. Even if the address is not
currently remapped, AddrTranslateP_getLocalAddr allows code to be more easily
ported. AddrTranslateP_getLocalAddr also prevents later versions of code from
breaking if address translation is added.

How does AddrTranslateP_getLocalAddr generate a local view of the base
address?

#. Pass the ACTUAL system address to AddrTranslateP_getLocalAddr.
AddrTranslateP_getLocalAddr checks whether the system address is in an
address range that was remapped:

#. If the address range is not remapped, then AddrTranslateP_getLocalAddr
sets localAddr = systemAddr

#. If the address is remapped, then AddrTranslateP_getLocalAddr translates
the localAddr

#. Every function call that interacts with that peripheral would use the
localAddr value.

Note that TI does NOT support using the MCU+ PRUICSS driver to control the PRU from the M4F. This is also true for the upcoming SDK 8.4 release.

On AM64x, the R4F is able to use the PRUICSS driver to initialize and control the PRU.

For more information on which CPU cores can use which drivers, reference the MCU+ release notes:

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/08_03_00_07/exports/docs/api_guide_am62x/RELEASE_NOTES_08_03_00_PAGE.html
https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_03_00_18/exports/docs/api_guide_am64x/RELEASE_NOTES_08_03_00_PAGE.html

So on AM62x, the Linux A53 cores will need to load and initialize the PRU cores, and PRU RPMsg is only supported between Linux and PRU. However, the M4F would still be able to read and write to PRU memory. I have not looked at whether interrupts can be mapped between PRU and M4F at this point in time.

Regards,

Nick