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.

TDA2: Configuring MPU MMU

Part Number: TDA2


Hello,

With starterware we are using both MPU A15 cores and want to configure the MPU_MMU to use cache but still retain the ability to use inter-core variables with DSP and IPU cores. We also want to have both A15 cores with MMU enabled running concurently. It seems like this would be possible by programming the MMU with specific tables/descriptors. To start we used the starterware example tables for MMU as a reference (found in mmu_a15_data_validation_app):

/* Set level one descriptor attributes */
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; /*Read Write at any PL*/

/* Set level one descriptor */
virtualAddr = 0x0, phyAddr = 0x0;
MMUA15SetFirstLevelDesc(&gMmuTable, virtualAddr, phyAddr, &gAttrs);
virtualAddr = 0x40000000, phyAddr = 0x40000000;
MMUA15SetFirstLevelDesc(&gMmuTable, virtualAddr, phyAddr, &gAttrs);
virtualAddr = 0x80000000, phyAddr = 0x80000000;
MMUA15SetFirstLevelDesc(&gMmuTable, virtualAddr, phyAddr, &gAttrs);
virtualAddr = 0xc0000000, phyAddr = 0x80000000;
MMUA15SetFirstLevelDesc(&gMmuTable, virtualAddr, phyAddr, &gAttrs);


With the values above if you attempt to print while MMU is enabled nothing gets printed. Similarly any attempt to use mailbox functions while MMU is enabled will fail. We can get both those to work by changing the 0x40000000 entry to MMU_A15_ATTR_INDEX_1.
1. Is it correct in that chaging to MMU_A15_ATR_INDEX_1 it is just disabling cache for this address block?
2. Would this be the recommended way for retaining access to UART, Mailbox, DMA,...?

When MMU is enabled we've observed inter-core variables that exist in external DDR mismatch between cores. An example is writing to a variable in DDR space on an A15 with MMU enabled and having an IPU core check the value. When MMU is enabled the IPU core does not read back what A15 just wrote but if MMU is disabled then IPU core reads back the correct value every time.
3. Is the mismatch due to A15 using cache and not actually writing it back to DDR?
4. Is there a way to make sure what A15 writes while MMU is enabled gets written to DDR?
5. What is the correct way to create a 16MiB section in DDR that would have its own table entry and use MMU_A15_ATR_INDEX_1? Couldn't find how to change sizes in the function MMUA15SetFirstLevelDesc().

Thank you,

JMG

  • Hi,

    What are the values for ATTR_INDEX_1?
    Can you check the A15 MMU large descriptor documentation for details on page size.

    Regards,
    Rishabh
  • Hello Rishabh,

    Not sure I understand your question. The value for ATTR_INDEX_1 is defined as 1 inside the file mmu_a15.h, though it's called MMU_A15_ATTR_INDEX_1.

    The struct that ATTR_INDEX_1 gets used in is called mmuA15DescriptorAttrs_t and the specific field is attrIndx. That struct field has the following description which I don't really understand.

    uint32_t attrIndx;
    /**< Bits[4:2]
    * Memory Attributes field, for Memory Attriute Indirection Register MAIR
    * Bit[4]:0 Use MAIR0, 1:Use MAIR1
    * AttrIndx[2:0] gives the value of m in Attrm
    * Attrm[7:4] 0100 Normal memory, outer non-cacheable
    * 1011 Normal memory, outer write through cacheable
    * 1111 Normal memory, outer write back cacheable
    * Attrm[3:0] 0100 Normal memory, inner non-cacheable
    * 1011 Normal memory, inner write through cacheable
    * 1111 Normal memory, inner write back cacheable
    */




    If ATTR_INDEX_1 is define as 1 then what does attrIndx=1 mean?

    I've reviewed the available information for MMU in the TDA2 TRM as well as reviewed MAIR register information provided on ARM's TRM website but I still don't understand how this value affects page size. Is there any chapter and section that you specifically recommend?

    Thanks,
    JMG
  • Hi,

    You need to check chapter B3.6 Long-descriptor translation table format of ARM Architecture Reference Manual for A15.
    TI software supports two level tables. So this means you can either have 1 GB region or 2 MB memory region.
    For 16 MB you need to map 8 second level entries.
    Application needs to take care of handling cache operation correctly. One point to keep in mind is that on A15 cache invalidate behaves similar to cache write back invalidate. This can have serious implications as valid data might get overwritten by stale data from cache.

    Regarding my question on ATTR_INDEX_1, you can use it to set inner and outer cacheable property of A15 cache.
    You can choose to set any value for index 1 using MMUA15SetMAIR API (like 0xFF is set for index 2 in example).
    The same should be set while setting mmuA15DescriptorAttrs_t.attrIndx.

    Regards,
    Rishabh
  • Hi,

    Is there any update on this?

    Regards,
    Rishabh
  • Hello Rishabh,

    Sorry for the delay, I was able to get back on this project and unfortunately I'm still not sure how I need to configure the MMU to accomplish my goal. More specifically, I'm not sure how to program the MMU using the functions provided as part of Starterware.

    Using the function MMUA15SetMAIR() I've tried to configure the attr[7:0] fields so that only the memory range from 0x8000.0000-0xC000.0000 is cacheable but I don't think I'm configuring it correctly. When I use

    MMUA15SetMAIR(&gMmuTable, MMU_A15_ATTR_INDEX_2, 0xFF);

    I see a noticeable increase in speed but I also lose the ability to use some functions, i.e. mailboxsend, uartprint, etc... Changing the third field to anything other than 0xFF, like 0xBB instead, makes it so I don't lose the utility of those functions but I also don't see any speed difference from when MMU is disabled. Since 0xBB would configure it as cacheable but write-through that makes sense that it would be as slow as if no MMU. At least that's how I understand it; is that correct?

    I've tried programming more than one ATTR_INDEX_# each with their own memory range and specific settings for that range but nothings has worked so far. If write-back settings (0xFF) are the only way I can see an increase in speed then is there a way to force a sync between what's in cache and what's in main memory? It may be that my inability to use the functions when 0xFF is used is only because of the differences between main memory and cached memory.

    The example provided in starterware (mmu_a15_data_validation_app_main.c) also disable MMU when it uses UART so I'm wondering, is my goal even achievable? Can I have MMU and cache capability enabled and still maintain the ability to use mailbox and uartprint functions?

    To recap my goal, I want to configure my DDR space as cacheable but still have the ability to use mailbox functions and UART print statements. Additional to that, if possible I'd like to have the same MMU configuration on both A15 cores, A15_0 and A15_1 so that each can operate independently.

    Can can you confirm that desired is goal is achievable? Also, if it is achievable are there any other examples that help demonstrate the different ways to configure MMU within starterware?

    Thank you.

  • Hi,

    In order to get performance improvement you should set the policy to write back. You should use the cache write-back/invalidate APIs to make sure the main memory is coherent with cache in case of any critical data access. Please note that the invalidate instruction is treated by A15 as a clean/invalidate instruction. Therefore, calls to Cache_inv()/Cache_invAll() will behave like Cache_wbInv()/Cache_wbInvAll() on A15.
    Also A15 has different L1D/L1P cache per core and an unified L2 cache.
    Ideally you should not be facing any issues with Mailbox or UART APIs with cache/MMU enabled. Can you elaborate on the issues you are facing?

    Regards,
    Rishabh
  • Hi,

    I haven't heard back from you, I'm assuming you were able to resolve your issue.
    If not, just post a reply below (or create a new thread if the thread has locked due to time-out).

    Regards,
    Rishabh