TDA2EVM5777: Accessing 4GiB DDR Range Starteware

Hi,

Our expert for this is not in office this week. Please expect delay in response, we will get back to you by early next week.

Regards,

Ankur

Hello Ankur,

Thank you for your reply, looking forward to hearing back when the expert returns. We made some progress in the MLO (Question 1) and continuing to learn more about the A15 memory access (Question 2). Here are additional details/questions, in addition to our previous post. Thank you for your help!

For the MLO we followed the example of what Linux does and configured
MA_MPU_LISA_MAP_0 = 0x0
MA_MPU_LISA_MAP_1 = 0x0
MA_MPU_LISA_MAP_2 = 0x80740300U
MA_MPU_LISA_MAP_3 = 0xFF020100U
DMM_LISA_MAP_0 = 0x80740300U
DMM_LISA_MAP_1 = 0xFF020100U
DMM_LISA_MAP_2 = 0x0
DMM_LISA_MAP_3 = 0x0

With this updated change, this does allow us to access beyond the 1GiB space up until the last 16MiB of the 2nd 1GiB range. (Due to the 0xFF020100U configuration that seems to be correct.)

In addition to the previous two questions (Question 1 and 2 in previous post), below are new Questions

Question 3: Is there a reason why we would need to have the 16MiB exclusion when not using Linux?

Based on further reading, in order to access the extended 2GiB of physical memory the a15 needs to set TTBCR to enable LPAE? The provided MMUA15Init() function calls MMUA15InitASM() which seems to set the TBCR EAE bit to non-zero.

MMUA15InitASM:
mov r0, #1 @ TTBR0 used and desc uses Short format
lsl r0, r0, #31 @ Set TTBCR.EAE bit
mcr p15, #0, r0, c2, c0, #2 @ write r0 to TTBCR
isb @ flush instruction pipeline
@ isb makes sure cp15 changes
@ are visible to all subsequent
@ instructions

bx r14
.endfunc

Question 4: Does the MMUA15InitASM() routine therefore enable LPAE?
Question 5: If yes, then do we only need to create First Level Descriptor Tables that point to the extended 2GiB physical addresses? And if yes, to access all of the 4GiB space from an A15 what would be the recommended configuration for the first level descriptors?
Question 6: This is an Application level function, is there no additional requirement in the MLO for accessing the extended memory?

Additionally we've seen that in Linux it appears that for LPAE mode a cache option is changed from (DCACHE_WRITEBACK & ~TTB_SECT_XN_MASK) to DCACHE_WRITEALLOC.
Question 7: What is the difference in cache management when using LPAE?

Thank you.

Hello Rishabh,

Thank you for confirming the 3GiB limit in starterware. Is there a plan to eventually support 4GiB in starterware/pdk?  
Also, I have some follow-up questions on your suggested mapping of the two 512MiB ranges below. Thanks again for your help!

How To Configure A15 Access of the 3GiB
Would accessing the extended 1GiB be done through the A15 MMU and virtually mapping the suggested ranges to extended DDR space? 
If so, the MMU first level descriptors define a 1GiB block which won't work for the suggested mapping of two 512MiB ranges… So does that mean the second level descriptors are the only way to map the two 512MiB blocks? Are there examples that do this type of mapping?

When to Configure Access
When does the MMU need to be configured If we wish to initialize global variables in the extended DDR space? 
Since the MLO loads the app would the MMU init need to be inside the MLO before the RPRCs are loaded? 

Thank you

Hello Rishabh,

Another task at work took my attention last week. Thank you for the above replies they have helped better understand how to access the additional 1GiB of space. After reviewing the 2nd level descriptor functions they seemed very similar to 1st level and I am programming them with very similar methods. I have kept the same mmuA15DescriptorAttrs configurations in 2nd level descriptors as 1st level and are now trying to correctly map the suggested two 512MiB ranges to their correct physical addresses.

I checked the MA_PRIORITY register to confirm the value of HIMEM_INTERLEAVE_UN and I saw it was set to 0. Under this configuration would the extended 1GiB physical addresses be:

EMIF1_SDRAM_CS0 = 0x02_0000_0000 0x02_3FFF_FFFF
EMIF2_SDRAM_CS0 = 0x03_C000_0000 0x03_FFFF_FFFF

The above is for the full extra 2GiB so are any two 512MiB sections in that range good to map to or are there any restrictions?

We'll want to use interleaving for this extended 1GiB space. Is enabling HIMEM_INTERLEAVE_UN the only requirement or are there any other configuration registers for the extended DDR?
Once interleaving is enabled, would the physical address range to map to be 0x02_0000_0000 0x02_3FFF_FFFF?

Thank you.

Hello Rishabh,

Thank you again for your reply and suggestions. 

I configured a LISA_MAP register with the goal of mapping the first 512MiB block using the register value: 0x20500140. 

However any attempt to read any value from 0x2000.0000 - 0x3FFF.FFFF results in a system halt. I've tried this with and without enabling the MMU with the second level descriptors. I'm still confirming I'm programming the second level descriptor correctly, below is an example of 1 out of 256 entries I created for the first 512MiB block. 

MMUA15InitDescAttrs(&gAttrs);
gAttrs.descriptorType = MMU_A15_DESCRIPTOR_TYPE_BLOCK;
gAttrs.attrIndx = MMU_A15_ATTR_INDEX_2;
gAttrs.nonSecure = MMU_A15_NON_SECURE_ENABLE;
gAttrs.accPerm = MMU_A15_ACC_PERM_RW_ANY_PL;

MMUA15SetSecondLevelDesc(&gMmuTable, 0x20000000, 0x20000000 , &gAttrs);



I used the case examples from the TDA2 TRM under the section "Addressing Management with LISA" to help derive the LISA register value. The second level descriptor header looked very similar to first level so I'm programming them with similar approach and since the function returned STW_SOK that seemed OK. 

Is there anything incorrect that you can see or any suggestions for how to debug the halt?

Thank you

Hello Rishabh

Thank you so much for the detailed suggestions. I translated the sys bios functions as best I could to use the PDK functions. After updating the LISA_MAP registers with what you suggest (2GiB on Emif 1, and 1 GiB on EMIF2) I get a full system halt as soon as I enable the MMU. Always at MMUA15Enable() I get a halt. I've started pulling up sys bios documentation to better understand your suggestion but I also have some followup questions.

1. I tried to match the configurations for the descriptor attributes but I'm not familiar with sys bios and couldn't find information on values that get set as part of Mmu.initDescAttrsMeta. I used MMUA15InitDescAttrs() and then updated any specific attributes like you manually did. Is what I'm using below correct?

2. For the EMIF2 configuration I see you're mapping to physical addresses starting at 0x3_0000_0000 but I wasn't sure why. The TRM I have lists that address as RESERVED. Can you explain why use that address?

3. BTW based on you using the full lower 1GiB address range for Emif 2 our max DDR range should be 3.5 GiB if we also use the initially suggested 512MiB range starting at 0x6000_0000 correct?

/***********************************************************

***********************************************************/

MMUA15InitDescAttrs(&table_gAttrs);
table_gAttrs.descriptorType = MMU_A15_DESCRIPTOR_TYPE_TABLE;

// Set level one descriptor
virtualAddr = 0x00000000, phyAddr = 0xc0000000;
MMUA15SetFirstLevelDesc(&gMmuTable, virtualAddr, phyAddr, &table_gAttrs);
virtualAddr = 0x40000000, phyAddr = 0xc0000000;
MMUA15SetFirstLevelDesc(&gMmuTable, virtualAddr, 0xc0000000, &table_gAttrs);
virtualAddr = 0x80000000, phyAddr = 0xc0000000;
MMUA15SetFirstLevelDesc(&gMmuTable, virtualAddr, phyAddr, &table_gAttrs);
virtualAddr = 0xc0000000, phyAddr = 0xc0000000;
MMUA15SetFirstLevelDesc(&gMmuTable, virtualAddr, 0xc0000000, &table_gAttrs);

cacheEnabled = CACHEA15GetEnabled();
// In case cache is disabled, invalidate and enable it
if (CACHE_A15_TYPE_ALL != cacheEnabled)
{
    CACHEA15InvalidateL1DAll();
    CACHEA15InvalidateL1IAll();
    CACHEA15Enable(CACHE_A15_TYPE_L1);
}

// Initialize MMU module
MMUA15Init();
// Set MAIR to inner and outer cacheable
MMUA15SetMAIR(&gMmuTable, MMU_A15_ATTR_INDEX_2, 0xFF);
// Initialize descriptor attributes
MMUA15InitDescAttrs(&gAttrs);
// Set level one descriptor attributes
gAttrs.descriptorType = MMU_A15_DESCRIPTOR_TYPE_BLOCK;
gAttrs.attrIndx = MMU_A15_ATTR_INDEX_2;
gAttrs.shareable = 2; ///MMU_A15_SHAREABLE_OUTER
gAttrs.nonSecure = MMU_A15_NON_SECURE_ENABLE;
gAttrs.accPerm = MMU_A15_ACC_PERM_RW_ANY_PL;

// Set the descriptor for each entry in the address range - EMIF 2 (1 GB)
for (t=0x00000000; t < 0x40000000; t = t + 0x00200000)
{
    // Each 'BLOCK' descriptor entry spans a 2MB address range
    MMUA15SetSecondLevelDesc(&gMmuTable, t, t + 0x300000000, &gAttrs);
}

// Set the descriptor for each entry in the address range - EMIF 1 (1 GB)
for (t=0x80000000; t < 0xC0000000; t = t + 0x00200000)
{
    // Each 'BLOCK' descriptor entry spans a 2MB address range
    MMUA15SetSecondLevelDesc(&gMmuTable, t, t, &gAttrs);
}

// Set the descriptor for each entry in the address range - EMIF 1 (1 GB)
for (t=0xC0000000; t < 0x100000000; t = t + 0x00200000)
{
    // Each 'BLOCK' descriptor entry spans a 2MB address range
    MMUA15SetSecondLevelDesc(&gMmuTable, t, t, &gAttrs);
}

// Set OCMC memories as shareable and cacheable in case Board package is used
for (t=0x40000000; t < 0x40600000; t = t + 0x00200000)
{
    // Each 'BLOCK' descriptor entry spans a 2MB address range
    MMUA15SetSecondLevelDesc(&gMmuTable, t, t, &gAttrs);
}

MMUA15SetMAIR(&gMmuTable, MMU_A15_ATTR_INDEX_1, 0x00);
gAttrs.attrIndx = MMU_A15_ATTR_INDEX_1;
gAttrs.accPerm = MMU_A15_ACC_PERM_RW_PL1;
gAttrs.shareable = 2; ///MMU_A15_SHAREABLE_OUTER
gAttrs.noExecute = 1; ///Enable
// Remaining OCMC region configured as non-cacheable, device memory.
for (t=0x40600000; t < 0x60000000; t = t + 0x00200000)
{
    // Each 'BLOCK' descriptor entry spans a 2MB address range
    MMUA15SetSecondLevelDesc(&gMmuTable, t, t, &gAttrs);
}

MMUA15Enable(&gMmuTable);

Thank you

Hello Rishabh,

I completely agree and was using your suggestion directly with only 3GB. The question about 3.5GB was just for determining max potential for planning purposes.

I'm not at all familiar with sys bios including its build process so I'm not sure how quick that may actually be. Using linux we've already validated the hardware so ultimately we just need to have the 3GB work in PDK. 

Since the system halts only when enabling the MMU it seemed the issue was MMU configuration but I thought I implemented the pdk version same as the posted sysbios version. Based on the software I provided is there any mistakes you can identify? 


Thank you