Arm Community
Site
Search
User
Site
Search
User
Groups
Arm Research
DesignStart
Education Hub
Graphics and Gaming
High Performance Computing
Innovation
Multimedia
Open Source Software and Platforms
Physical
Processors
Security
System
Software Tools
TrustZone for Armv8-M
中文社区
Blog
Announcements
Artificial Intelligence
Automotive
Healthcare
HPC
Infrastructure
Innovation
Internet of Things
Machine Learning
Mobile
Smart Homes
Wearables
Forums
All developer forums
IP Product forums
Tool & Software forums
Support
Open a support case
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Developer Community
IP Products
Processors
Jump...
Cancel
Processors
Cortex-A / A-Profile forum
ARM Cortex-A9 | Non-cacheable memory range
Blogs
Forums
Videos & Files
Help
Jump...
Cancel
New
Replies
9 replies
Subscribers
273 subscribers
Views
10765 views
Users
0 members are here
Cortex-A9
Cortex-A
Memory
Related
ARM Cortex-A9 | Non-cacheable memory range
Offline
S R Chidrupaya
over 7 years ago
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
Offline
Scott Douglass
over 7 years ago
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.
Cancel
Up
0
Down
Reply
Cancel
Reply
Offline
Scott Douglass
over 7 years ago
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.
Cancel
Up
0
Down
Reply
Cancel
Children
No data
More questions in this forum
By title
By date
By reply count
By view count
By most asked
By votes
By quality
Descending
Ascending
All recent questions
Unread questions
Questions you've participated in
Questions you've asked
Unanswered questions
Answered questions
Questions with suggested answers
Questions with no replies
Answered
Asynchronous External abort
0
3469
views
3
replies
Latest
2 months ago
by
Ranjith_
Not Answered
Query related to function call compiled in AARCH32 execution state from AARCH64 bit space
0
8590
views
2
replies
Latest
2 months ago
by
42Bastian Schick
Answered
what does "Synchronous exception from Current EL with SP_ELx" mean?
0
Arm Trusted Firmware
AArch64
ARMv8 Exception Model
3135
views
1
reply
Latest
2 months ago
by
42Bastian Schick
Not Answered
How Can I Synchronize the Generic Timer values in different PEs in the same Core?
0
Cortex-A35
Armv8-A
10280
views
1
reply
Latest
2 months ago
by
Zhifei Yang
Not Answered
Arm Trusted firmware as bootloader for A53
0
Cortex-A53
U-Boot
10083
views
3
replies
Latest
2 months ago
by
Zhifei Yang
<
>
View all questions in Cortex-A / A-Profile forum