[AM57xx] IPU AMMU 独家专解

1. About the AMMU:

Sorry for the confusion. Given you are using QNX and not SYSBIOS on the host, the situation is different. IPC has a different set of examples that support loading and starting the IPUs from the A15. These examples configure the AMMU solely in the .cfg file. There is no need for GEL files, because the IPU code is loaded from the host (as opposed to from CCS). IPU memory is mapped as needed by the loader, based on the contents in the IPU executable and the resource table. Once the code is loaded, the IPU is started and it will configure the AMMU according to the .cfg file.
I suggest you take a look at the ex02_messageq example under <IPC_INSTALL_DIR>/examples/DRA7XX_qnx_elf to see how we configured the AMMU. For instance, ex02_messageq/ipu2/IpuAmmu.cfg has the configuration for IPU2.
Also, if you are using custom hardware with a different memory map, besides modifying the AMMU configuration you may need to provide your customized resource table and rebuild it alongside the slave executables in order for the examples to work. The resource table establishes the correspondence between the AMMU-translated virtual memory locations on the slave core — ie. the translated output from the AMMU – and physical memory locations. When loading the IPU, the IPC resource manager would parse through this resource table and program MMU0 accordingly. So ultimately a given virtual address issued by the IPU is double-translated thru both MMUs to access the corresponding physical location.
Here is a wiki topic on how to provide a custom resource table to override the default one in IPC:
http://processors.wiki.ti.com/index.php/IPC_Resource_customTable

When used within a dual M3 core (Ducati) arrangement, care must be taken when initializing this shared resource. The “Shared Resources” note provided in the ducati package discusses the management of the various hardware and software resources shared by the two M3 cores.
As the AMMU is shared between the two M3 cores, it should only be initialized and enabled once. It is intended that Core 0 will configure the AMMU at startup.

Shared Resources:
The two M3 cores share a number of hardware and software resources.
The system software must carefully manage these resources when the dynamic loading of applications is required.
Below is a list of the shared resources that SYS/BIOS modules utilize and manage.
Shared resources:
AMMU

Must be configured before unicache is enabled.
Must have a page descriptor for EVERY memory address accessed by either core before unicache is enabled.
AMMU is configured statically, no runtime APIs to modify the AMMU configuration are provided.
Initialization is controlled by the AMMU.configureAmmu flag.
By default, this flag is true. 

Unicache

Must be configured and enabled.
Runtime APIs use GateDualCore[0] to arbitrate shared unicache register usage.
Initialization is controlled by the Cache.configureCache flag.

By default this flag is false.

The DSP MMU is located on the boundary with the L3 and is programmed by the A9. The A9, in programming the DSP MMU, can restrict the DSP’s access to certain memory regions. The DSP MMU acts as a gatekeeper, so if the AMMU tries to program a region not allowed by the DSP MMU, a fault will occur. Since the details of the DSP MMU are not in the public domain, you will need to contact your TI representative directly for more specific information.

A virtual address is first translated by the AMMU, then by the IOMMU. The first is configured using the .cfg file that you are looking at. The second is programmed by the Linux loader when it loads the DSP. The mapping for the IOMMU is specified in the default resource table in <IPC_INSTALL_DIR>/packages/ti/ipc/remoteproc/rsc_table_omap5_dsp.h.

I do not see the 0x50000000 range being mapped in the resource table, so you will need to add an entry to translate it (a straight translation would do). This page talks about how to override the default resource table with your own customized one:

All memory accessed by the remote processors have to be defined in an Attribute-MMU (AMMU), and the AMMU also generates a XLATE_MMU_FAULT interrupt to the core.

Note:
一个很重要的点就是，根据AM57xx 的架构， M4有两级MMU，第一级MMU 为AMMU，第二级MMU 为IPUx_MMU.
AMMU: 是离M4核最近MMU， 但M4 要寻址时，首先访问AMMU（在unicache 打开的情况下），所以AMMU 要确保惟一的访问地址。而在DSP的观点上，L3 互联上的地址范围为0x0000 0000 ~0xFFFF FFFF,当然这里有很多重复的地址空间，但总之IPU 有自己的私有寻址空间 和L3 重复。所以M4 又加了一个IPUx_MMU。
IPUx_MMU:
IPUx_MMU 是连接在L3 端口的MMU， 负责将L3 空间的物理地址转换为虚拟地址， 转换的控制在resource table 中。

我们在overwrite 这个resource table 时，应该注意我们映射出来的虚拟地址要确保不能和 控制 AMMU映射的文件（ipuammu.cfg） 映射出来的虚拟地址有重复， 因为在AMMU 的观点上要保证虚拟地址的一致性。

我们使用一张图再来加以说明(仅当AMMU 使能时)：