AM572x IPU memory map understanding

Apoorva Nagarajan

Hi,

We are using PSDK 02_00_00_00. We are using the H264 encoders and decoders from the PSDK. We wanted to understand the IPU MMU configuration done by the DCE server.

From our understanding, the MMU configurations are done through "IpuAmmu.cfg" file. We see that there is a large page with logical address 0x0 and the translation is disabled. With this information, it seems like, physical address is 0x0.

/* Instruction Code: Large page (512M); cacheable */
/* config large page[0] to map 512MB VA 0x0 to L3 0x0 */
AMMU.largePages[0].pageEnabled = AMMU.Enable_YES;
AMMU.largePages[0].logicalAddress = 0x0;
AMMU.largePages[0].translationEnabled = AMMU.Enable_NO;
AMMU.largePages[0].size = AMMU.Large_512M;
AMMU.largePages[0].L1_cacheable = AMMU.CachePolicy_CACHEABLE;
AMMU.largePages[0].L1_posted = AMMU.PostedPolicy_POSTED;

In the IPUMM configuration file "config.bld", we see that the "EXT_CODE" section is at 0x00004000.

var evmDRA7XX_ExtMemMapIpu2 = {
EXT_CODE: { name: "EXT_CODE", base: 0x00004000, len: 0x005FC000, space: "code", access: "RWX" },
EXT_DATA: { name: "EXT_DATA", base: 0x80000000, len: 0x00200000, space: "data", access: "RW" },
EXT_HEAP: { name: "EXT_HEAP", base: 0x80200000, len: 0x02900000, space: "data", access: "RW" },
TRACE_BUF: { name: "TRACE_BUF", base: 0x9F000000, len: 0x00060000, space: "data", access: "RW" },
EXC_DATA: { name: "EXC_DATA", base: 0x9F060000, len: 0x00010000, space: "data", access: "RW" },
PM_DATA: { name: "PM_DATA", base: 0x9F070000, len: 0x00020000, space: "data", access: "RWX" }
};

When we refer to the TRM IPU memory map, there are 2 entries for physical address 0x0: One is IPU boot space (16KB) and the other is GPMC (512MB)

In which region does the "EXT_CODE" segment for dce server reside? GPMC does not seem to be a correct mapping for IPU. Is there any internal memory for this region?

Regards,

Apoorva

over 9 years ago

0 Rahul Prabhu over 9 years ago

TI__Guru** 116830 points

Apoorva,

Please refer to footnote (1) provided at the end of the IPU memory table. When IPU wakes up, the IPU AMMU is loaded by this configuration in hardware in the small page of the AMMU

var entry = AMMU.smallPages[0];
entry.pageEnabled = AMMU.Enable_YES;
entry.translationEnabled = AMMU.Enable_YES;
entry.logicalAddress = 0x00000000;
entry.translatedAddress = 0x55020000;
entry.size = AMMU.Small_16K;
entry.L1_cacheable = AMMU.CachePolicy_NON_CACHEABLE;

this entry can`t be modified in software as far as I can tell.

This means that when IPU issues an access with address 0x00000000-0x000004000 then the address is translated by the AMMU to base of the RAM (0x55020000-0x55024000) by default in hardware.

It also mean that the initial 16 KB of the GPMC address space is not available for IPU to access using direct address mapping. you will need to configure the AMMU to use unused 16KB from its memory map to redirect to L3 addresses from (0x0 to 0x00003FFFF) inorder to access lower 16KB from the GPMC address space.

Hope this clarifies the IPU memory map and MMU configurations.

Regards,
Rahul

0 Apoorva Nagarajan over 9 years ago in reply to Rahul Prabhu

Intellectual 505 points

Thanks Rahul for the explanation, the first 16KB is mapped to 0x55020000-0x55024000, but the code section is present beyond 16KB

EXT_CODE: { name: "EXT_CODE", base: 0x00004000, len: 0x005FC000, space: "code", access: "RWX" }

We are not clear as to which part of the memory does 0x00004000 map to. Is this also mapped to IRAM via some other small page? Can you please help us?

Regards,
Apoorva

0 Rahul Prabhu over 9 years ago in reply to Apoorva Nagarajan

TI__Guru** 116830 points

Apoorva,

Can you point me to the package where you are seeing the memory definition for EXT_CODE as you have mentioned in the post:

EXT_CODE: { name: "EXT_CODE", base: 0x00004000, len: 0x005FC000, space: "code", access: "RWX" }

This may be a custom memory mapping used in the AMMU as this space is not defined in the IPU memory map.

IPU has a RAM 64KB region is defined at 0x5502_0000 from which you can run your code and example of how to do the AMMU setup is described in

pdk_am57xx_1_0_3\packages\ti\drv\spi\example\mcspi_serializer\am572x\m4\bios\spi_m4_idkAM572x.cfg

Regards,
Rahul

0 Buddy L. over 9 years ago in reply to Rahul Prabhu

TI__Intellectual 2540 points

Hi Apporva,

The IPUMM config.bld file shows the memory map configuration that is used for IPUMM. Through the IPC 3.x that supports for loading slave images, IPC has the ability for users to override the default resource table. IPUMM has taken the copy of IPC 3.x resource table (custom_rsc_table_vayu_ipu.h) to make it custom for client.

For more information about IPC3.x Resource table: http://processors.wiki.ti.com/index.php/IPC_Resource_customTable?keyMatch=IPC%20resource%20table&tisearch=Search-EN

Now for your question in regards to:

EXT_CODE: { name: "EXT_CODE", base: 0x00004000, len: 0x005FC000, space: "code", access: "RWX" }

In which region does the "EXT_CODE" segment for dce server reside? GPMC does not seem to be a correct mapping for IPU. Is there any internal memory for this region?

You are correct that EXT_CODE in IpuAmmu.cfg resides in L1 unicache MMU:

/* config large page[0] to map 512MB VA 0x0 to L3 0x0 */
AMMU.largePages[0].pageEnabled = AMMU.Enable_YES;
AMMU.largePages[0].logicalAddress = 0x0;
AMMU.largePages[0].translationEnabled = AMMU.Enable_NO;
AMMU.largePages[0].size = AMMU.Large_512M;
AMMU.largePages[0].L1_cacheable = AMMU.CachePolicy_CACHEABLE;
AMMU.largePages[0].L1_posted = AMMU.PostedPolicy_POSTED;

IPUMM config.bld shows that IPUMM is defining the EXT_CODE at da = 0x00004000 of size 0x005FC000. As you can see on the custom_rsc_table_vayu_ipu.h, the entry for IPU_MEM_TEXT is started at

#define IPU_MEM_TEXT 0x0

#define IPU_MEM_TEXT_SIZE (SZ_1M * 6)

In IPUMM config.bld, it is only using 5.984375 MB of that memory. As described in the resource table wiki "These carveouts tell remoteproc to allocate memory from its CMA area and map the allocated physical address to the virtual address specified in the carveout (the 1st field after TYPE_CARVEOUT)"

So, the physical address will be allocated and mapped (through L2 MMU) from its CMA area which should have been reserved at Linux kernel Device Source Tree (DTS) file.

To see the corresponding physical address for 0x00004000, you can run this command at Linux prompt:

# cat /sys/kernel/debug/omap_iommu/55082000.mmu/pagetable

eg.

L: da: pte:

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

1: 0x00000000 0x94100002

1: 0x40000000 0x40040002

1: 0x40100000 0x40040002

1: 0x40200000 0x40040002

1: 0x40300000 0x40040002

1: 0x40400000 0x40040002

1: 0x40500000 0x40040002

1: 0x40600000 0x40040002

1: 0x40700000 0x40040002

1: 0x40800000 0x40040002

So in the eg., da = 0x00000000 correspond to pa = 0x94100000

For da = 0x00004000, it corresponds to pa = 0x94104000

Thanks.

//Buddy

0 mohnish jain over 9 years ago in reply to Buddy L.

Prodigy 180 points

Thanks for the detailed explanation. We are having an issue that we are not able to achieve 60fps performance with IVAHD H264 codecs using standalone binary. We have explained the same in this e2e post.

Earlier we were suspecting Tiler but then we figured out that PSDK 2.0.0.0 Linux code with remoteproc works fine without Tiler. We have ensured most of the things like IPU clock, DDR clocks and IVAHD clocks are set to maximum. DMM initiator priorities are also proper.

We understood that the Linux is using IPU2_MMU (L2 MMU) for doing these mappings. In our case, we do the mappings only through IPU_UNICACHE_MMU(L1 MMU). We do not configure the IPU2_MMU (L2 MMU). Can this be a reason for low throughput? We are able to achieve 56 fps performance with the codecs.

Thanks,

Mohnish

0 Darshan Patel7 over 8 years ago in reply to mohnish jain

Intellectual 455 points

Hi Mohnish,

Can you please explain how you have taken care of "DMM initiator priorities" (as mentioned by you in post)?

I want to set Highest priority to IVAHD for DDR Access.

0 Manisha Agrawal over 8 years ago in reply to Darshan Patel7

TI__Mastermind 22946 points

Check section 15.2.3.5.3.3 PEG Description of TRM document to set the DMM Peg priority register. Refer to Table 14-10. ConnID Values for the connId value of IVA. Per that table, ConnID value of IVA is E. That makes DMM_PEG_PRIO_k register physical address for IVA as 0x4E000624, the 4 bit nibble to change is P6. To set IVA as highest priority for accessing DDR, use devmem2 tool as follows

#devmem2 0x4E000624 w 0x48444444

Note that 4th bit is write enable bit and hence the nibble holding value 8.

0 Darshan Patel7 over 8 years ago in reply to Manisha Agrawal

Intellectual 455 points

Thanks for your input Manisha. I could adjust the DMM priorities.

Processors

Processors forum

AM572x IPU memory map understanding