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

Cacheable setting in TTBR and Page descriptors

KyongHo Cho
Note: This was originally posted on 24th February 2010 at http://forums.arm.com

Hi there!

While reading the ARMv7-AR reference manual,
we have to configure cacheable settings on both of TTB registers and page descriptors.

The followings list same settings in TTBR and page descriptors:
S : shareable
RGN / TEX,C,B : inner and outer cacheable

As I know, TEX, C, B and S bits in the page descriptors are applied to the page described by the page descriptor.

I guess the meaning of S and RGN bits in TTBR as below:
1. those bits are not the settings for pages related to the TTBR but for page tables themselves.
   But I don't think this is correct because there is already a cache for page tables, TLB.
2. those bits are the settings for the whole address space of a task whose page table is
   referenced by the current TTBR. Cacheability and shareability settings in the page descriptors
   override that settings in TTBR.

Thank you in advance!;
Parents
  • Arm Employee Badge
    Note: This was originally posted on 24th February 2010 at http://forums.arm.com

    You are correct that the TLBs are caches, they cache recently used translataions.  The RGN:S:C bits control whether the data cache is used for table walks.  So when the MMU has to read the pagetables to perform a translation - will it look in the data cache? 

    Why do this?  Well, the page tables are really just data.  So if you were to modify the page tables (e.g. due to demand paging), this would be a data operation.  If the region is marked as cacheable, then it is likely the modifications are in the data cache.  Previous generations of ARMs could not check the D cache when doing a MMU table walk.  So you _had_ to do a D cache clean.  With the Cortex family, you can use the additional bits in the TTBRs to decide whether to check the caches or not.
Reply
  • Arm Employee Badge
    Note: This was originally posted on 24th February 2010 at http://forums.arm.com

    You are correct that the TLBs are caches, they cache recently used translataions.  The RGN:S:C bits control whether the data cache is used for table walks.  So when the MMU has to read the pagetables to perform a translation - will it look in the data cache? 

    Why do this?  Well, the page tables are really just data.  So if you were to modify the page tables (e.g. due to demand paging), this would be a data operation.  If the region is marked as cacheable, then it is likely the modifications are in the data cache.  Previous generations of ARMs could not check the D cache when doing a MMU table walk.  So you _had_ to do a D cache clean.  With the Cortex family, you can use the additional bits in the TTBRs to decide whether to check the caches or not.
Children
No data