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 使能時)：
