• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 349 subscribers
  • Views 15690 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM Cortex-A9 | Non-cacheable memory range

S R Chidrupaya
Note: This was originally posted on 23rd May 2013 at http://forums.arm.com

Hi all,


I am designing an application on  xilinx zynq 702 board which comes with two(core) arm cortex a9 processors. I am using one of the arm cores two run a part of the application which retrieves and stores data on DDR3(on zynq), that in turn is stored or retrieved by another part of the application running on microblaze(zynq).

For maintaining coherency between them I need to make the data accesses non-cacheable. Is there any provision on arm to make a range of memory non-cacheable during run-time?

Thanks

John
  • 0
    Note: This was originally posted on 5th June 2013 at http://forums.arm.com

    Hi Scott & isogen,

    Thank you very much. Scott, I guess that's the only way to move forward.  Thank you for helping me out.

    John
  • 0
    Note: This was originally posted on 28th May 2013 at http://forums.arm.com

    Hello Scott,


    Thank you for your suggestion. In my current design I'm using AXI-HP, so maintaining coherency falls on the part of application(baremetal). I understand that by following the procedures mentioned by you I can declare a section(1 MB or 4KB) of memory in the TLB as cacheable or non-cacheable. But the need is to declare a range of memory as non-cacheable. One way of doing this could be declaring a range of memory(at runtime) as non-cacheable(TTBR register) while performing TLB walks, when its included in the TLB. But I'm unable to get any further reference to this method.

    Can you please give any suggestion as to if the above mentioned path is feasible or do I need to follow any other possible way.


    Thanks

    John
  • 0
    Note: This was originally posted on 31st May 2013 at http://forums.arm.com

    Hi Scott,

    Thank you for clearing it up for me. I mean to change the memory attributes of the physical addresses themselves, but perhaps changing the bit field of the TTBRx registers would only change the way the TLB walks are peformed(on cacheable memory or not) , not really what I need. So from what I understand I have to change the memory attributes in the MMU table, but as I have informed there is a problem in that. I was hoping to achieve the remapping by changing the "cp15 c10" registers, but modifying the TLB entries or translation tables(thanks!) would result in the same problem. I do not find any other option for implementing this feature.
  • 0
    Note: This was originally posted on 3rd June 2013 at http://forums.arm.com

    Hi Scott and isogen,

    Thanks for clearing it up, Scott. But if I do use the table entries(or MMU) to remap the memory regions, as per my understanding, I've to do it for a section with size range(4kB - 1MB) which I want to avoid as my need is to declare only a range of memory as non-cacheable. If I'm missing anything; please suggest.

    John
  • 0 Arm Employee Badge
    Note: This was originally posted on 24th May 2013 at http://forums.arm.com

    The cacheability of a memory region is determined by the MMU tables.  If you're maintaining the MMU tables yourself then to switch from cacheable to non-cacheable you'd need to clean any dirty data for the region from the cache(s) and then change the MMU tale to make it non-cacheable.  The reverse is similar but there's no need to clean any cache.

    If you're using an OS then you'll have to get it to do the cache maintenance and MMU table updates.

    [size=2]Alternatively, if you can make use of the ACP on the Cortex-A9/SCU you can let it take care of cache coherency with another master.  How to do this on Zynq is something you'll need to ask Xilinx about.[/size]
  • 0 Arm Employee Badge
    Note: This was originally posted on 3rd June 2013 at http://forums.arm.com

    Yes, the smallest granularity of memory regions in the MMU tables is 4KB.  If you need finer resolution than that, I guess you'll have to do manual cache maintenance (that is, leave it cacheable and clean/invalidate as appropriate).
  • 0 Arm Employee Badge
    Note: This was originally posted on 30th May 2013 at http://forums.arm.com

    [Sorry to be picky, but by "in the TLB" I think you mean "in the translation tables".]

    The cacheability of a particular region of virtual addresses and the cacheablility of the translation tables themselves are two different things.

    When the MMU is on, a memory access goes something like this:

    1. The program wants to access a certain virtual address, V.

    2. If the translation info for (the region including) V is in the TLB then use it and skip to step 4.

    3. Otherwise, using physical addresses, walk the translation tables to find the translation info for (the region that includes) V.  The cacheability (L1/L2 data cache) of these physical accesses to the translation tables is determined by bits in TTBRx.  Store the translation info in the TLB for possible later re-use.

    4. Use the translation info to translate V to a physical address P and determine the memory attributes for the region.  These memory attributes determine whether or not the access to P can be cached (L1/L2).

    5. If P is cacheable and in the cache do the access to the cache.

    5. Otherwise, do the physical access to P and cache the result or not as appropriate.

    It's the cacheability in memory attributes as stored in the translation tables (used in step 4) that you seem to be interested in changing.

    It's possible (but perhaps unusual) to have no V->P mapping at all for the translation tables; they don't need to have a virtual address.  But if there is one then it's memory attributes need to match the TTBRx bits.
  • 0 Arm Employee Badge
    Note: This was originally posted on 3rd June 2013 at http://forums.arm.com


    Thank you for clearing it up for me. [...]  So from what I understand I have to change the memory attributes in the MMU table, but as I have informed there is a problem in that. I was hoping to achieve the remapping by changing the "cp15 c10" registers,


    Well, my description is a bit oversimplified.  It is possible to use "TEX remap" (SCTRL.TRE == 1) which means that the memory attributes are determined by using three bits in the translation table entries as an index into a table held the c10 registers (PRRR and NMRR).  So it is possible to set things up so that you can switch the Shareability by changing just the PRRR and/or NMRR registers (and doing the necessary TLB flushing).
  • 0 Arm Employee Badge
    Note: This was originally posted on 3rd June 2013 at http://forums.arm.com

    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]> So from what I understand I have to change the memory attributes in the MMU table[/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]Correct.[/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]> but as I have informed there is a problem in that. [/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]What problem are you hitting?[/size][/font][/color]
    [color=#222222][font=Arial, Helvetica, sans-serif][size=2]
    [/size][/font][/color]
    Note that the other option is to keep the memory cached, but perform cache maintenance to ensure coherency when needed.