Arm Community
Site
Search
User
Site
Search
User
Support forums
Arm Development Studio forum
mmu page table
Jump...
Cancel
Locked
Locked
Replies
2 replies
Subscribers
119 subscribers
Views
2971 views
Users
0 members are here
Options
Share
More actions
Cancel
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
mmu page table
Pan Wei
over 12 years ago
Note: This was originally posted on 22nd April 2013 at
http://forums.arm.com
hi
some question about MMU table.
background:
1.the CPU is ARM1176JS-Z.
2. L1 cache enabled
3.i want to enable MMU in bootloader, to simply it, i only introduce first-level page table.
4. the page table will not be changed after initialization
my question is that:
for the page table itself, where should i put it into? a cacheable area? or a noncacheable area? does MMU hardware access the page table through L1 cache?
both area(cacheable and noncacheable) i have tried, it looks both of them work.
i saw some other code put the page table into noncacheable area , so i want to know if it is must or not.
thanks in advances
BR
PanWei
Parents
Martin Weidmann
over 12 years ago
Note: This was originally posted on 22nd April 2013 at
http://forums.arm.com
The MMU can be configured either way, do walks through the L1 data cache or not.
For systems where you're modifying the tables frequently it can make sense to allow the MMU to do walks through the D cache. They way its working off the same cached copy as the code is using.
In your case, with static tables I wouldn't expect it to make much difference either way. I would probably mark the area as non-cachable and do non-cacheable table walks. That way I'd avoid polluting the d cache with table descriptors.
Cancel
Vote up
0
Vote down
Cancel
Reply
Martin Weidmann
over 12 years ago
Note: This was originally posted on 22nd April 2013 at
http://forums.arm.com
The MMU can be configured either way, do walks through the L1 data cache or not.
For systems where you're modifying the tables frequently it can make sense to allow the MMU to do walks through the D cache. They way its working off the same cached copy as the code is using.
In your case, with static tables I wouldn't expect it to make much difference either way. I would probably mark the area as non-cachable and do non-cacheable table walks. That way I'd avoid polluting the d cache with table descriptors.
Cancel
Vote up
0
Vote down
Cancel
Children
No data