• Locked Locked
  • Replies 2 replies
  • Subscribers 119 subscribers
  • Views 2964 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

mmu page table

Pan Wei
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
  • Arm Employee Badge
    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.
Reply
  • Arm Employee Badge
    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.
Children
No data