• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 349 subscribers
  • Views 15699 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
Parents
  • 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.
Reply
  • 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.
Children
No data