This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/AM5728: IPU memory mapping

Part Number: AM5728

Tool/software: TI-RTOS

I'm trying to understand the memory mapping and virtualization that is applied between IPU logical and physical addresses. I know that there are several layers of MMUs, with the AMMU being closest to the IPU core. My AMMU configuration gets set up in my SYS/BIOS project via a configuration file. I also understand that the MMU above the AMMU gets set up by the remoteproc driver in Linux based on the contents of a resource table I build into my IPU binary image. 

I've been using AMMU and resource table implementations from examples in TI's RTOS SDK as a guide but have a few questions about configuring the memory mapping:

1. I understand that virtualizing addresses to the external DDR is required because we don't necessarily know ahead of time how Linux will map DDR sections to the IPU. However when it comes to things like L4 peripheral memory and local IPU RAM/ROM/MMU registers, the examples all apply an offset to these addresses but this translation seems totally unnecessary to me. Am I missing something? Is there a reason we SHOULD do this? Stated differently, is there anything bad about passing peripheral and local memory addresses on directly to the IPU with no translation?

2. I've been using the IpuAmmu.cfg file from the IPC MessageQ example (\ipc_3_47_00_00\examples\DRA7XX_linux_elf\ex02_messageq\ipu2\IpuAmmu.cfg) as a baseline for my own config file. I noticed that there are some overlapping pages in this configuration. Specifically, consider the following which appears to have several small pages overlap within a medium page:

/* ISS: Use 3 small pages(1 4K and 2 16K) for various ISP registers; non-cacheable; translated */
/* config small page[6] to map 16K VA 0x50000000 to PA 0x55040000 */
/* non cacheable by default */
AMMU.smallPages[6].pageEnabled = AMMU.Enable_YES;
AMMU.smallPages[6].logicalAddress = 0x50000000;
AMMU.smallPages[6].translatedAddress = 0x55040000;
AMMU.smallPages[6].translationEnabled = AMMU.Enable_YES;
AMMU.smallPages[6].size = AMMU.Small_16K;

/* config small page[7] to map 16K VA 0x50010000 to PA 0x55050000 */
/* non cacheable by default */
AMMU.smallPages[7].pageEnabled = AMMU.Enable_YES;
AMMU.smallPages[7].logicalAddress = 0x50010000;
AMMU.smallPages[7].translatedAddress = 0x55050000;
AMMU.smallPages[7].translationEnabled = AMMU.Enable_YES;
AMMU.smallPages[7].size = AMMU.Small_16K;

/* config small page[8] to map 4K VA 0x50020000 to PA 0x55060000 */
/* non cacheable by default */
AMMU.smallPages[8].pageEnabled = AMMU.Enable_YES;
AMMU.smallPages[8].logicalAddress = 0x50020000;
AMMU.smallPages[8].translatedAddress = 0x55060000;
AMMU.smallPages[8].translationEnabled = AMMU.Enable_YES;
AMMU.smallPages[8].size = AMMU.Small_4K;

/*********************** Medium Pages *************************/
/* ISS: The entire ISS register space using a medium page (256K); cacheable; translated */
/* config medium page[0] to map 256K VA 0x50000000 to PA 0x55040000 */
/* Make it L1 cacheable */
AMMU.mediumPages[0].pageEnabled = AMMU.Enable_YES;
AMMU.mediumPages[0].logicalAddress = 0x50000000;
AMMU.mediumPages[0].translatedAddress = 0x55040000;
AMMU.mediumPages[0].translationEnabled = AMMU.Enable_YES;
AMMU.mediumPages[0].size = AMMU.Medium_256K;
AMMU.mediumPages[0].L1_cacheable = AMMU.CachePolicy_CACHEABLE;
AMMU.mediumPages[0].L1_posted = AMMU.PostedPolicy_POSTED;

What is the net effect of something like this, where multiple page definitions appear to re-map the same memory space? I'm also curious as to why these are re-mapped at all as the TRM shows the range 0x55030000 to 0x5507FFFF as "reserved" in the L3_MAIN memory map.