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

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!;

KyongHo Cho over 12 years ago

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

Thank you for your reply!

According to your answer, D-cache is used when MMU does translation table walk and when O/S manages page tables.
Are the RGN and S fields in TTBR applied to the both cases?

When looking into the source code of Linux,
O/S just writes a page descriptor to a virtual memory address as a ordinary data.
I thought that means RGN is not applied to this case.

If D-cache is also used by MMU while translation table walk,
are multiple page descriptors cached in D-cache and a page descriptor is cached in TLB whenever it is required?
Cancel
Vote up 0 Vote down

Cancel
Martin Weidmann over 12 years ago

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.
Cancel
Vote up 0 Vote down

Cancel
Martin Weidmann over 12 years ago

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

The RGN bits in the TTB registers are only used for table walks by the MMU,

For it to work reliably - the options chosen with the RGN bits must match what is used when accessing the same memory normally (e.g. due to modifying the page tables)
Cancel
Vote up 0 Vote down

Cancel
Robert Hockauf over 12 years ago

Note: This was originally posted on 3rd December 2010 at http://forums.arm.com

The RGN bits in the TTB registers are only used for table walks by the MMU,

For it to work reliably - the options chosen with the RGN bits must match what is used when accessing the same memory normally (e.g. due to modifying the page tables)

Hi,
could you provide me example settings? I tried on a Cortex-A8 (BeagleBoard) with the following settings, but still have to flush the data cache to get level 2 table changes effective. Level 1 table changes, however, become effective without the need to flush the data cache.

Page tables on cached memory (TEX=0, S=0, C=1, B=1)
TTB registers have RGN=11, C=1, S=0
Caches and BTB are enabled

Thanks a lot,
Robert
Cancel
Vote up 0 Vote down

Cancel