Translation table walk access caches

As ARM specification:

If an implementation includes the Multiprocessing Extensions, translation table walks must access data or unified 
caches, or data and unified caches, of other agents participating in the  coherency protocol, according to the 
shareability attributes described in the TTBR. These shareability attributes must be consistent with the shareability 
attributes for the translation tables themselves.

Now I have a dual-core Cortex-A9 CPU, but I just use one core.

So this means if I specified inner Cacheable attibute in TTBR, then when I update MMU table, I need not flush L1 Data Cache.

But with multiprocessing extentions, TTBR set cacheable with 2 bits:

IRGN, bits[6, 0], in an implementation that  includes the Multiprocessing Extensions Inner region bits. Indicates the Inner Cacheability attributes for the memory associated with the 

translation table walks. The pos sible values of IRGN[1:0] are:

0b00  Normal memory, Inner Non-cacheable.

0b01  Normal memory, Inner Write-Back Write-Allocate Cacheable.

0b10  Normal memory, Inner Write-Through Cacheable.

0b11  Normal memory, Inner Write-Back no Write-Allocate Cacheable.

My question is:

1 Do I must set the same attribute (WriteBack-WriteAllocate, WriteBack-NoWriteAllocate, WriteThrough) as the attribute of the memory in MMU tanslation table?

2 If they are not same, what will happen?

I do some experiments:

1 TTBR and MMU table set to "Inner Write-Back Write-Allocate Cacheable", program OK

2 TTBR set to "Inner Write-Back no Write-Allocate Cacheable" , MMU table set to "Inner Write-Back Write-Allocate Cacheable", program OK!!

3 TTBR set to "Write-Through Cacheable", MMU table set to "Inner Write-Back Write-Allocate Cacheable", program fail!!

I'm so confused. Translation table should only care "cacheable" or "non-cacheable". If it's "cacheable", it can get data from L1 DCache. If it's "non-cacheable", it access the memory directly. Why does it care write-back, write-through and write-allocate?

answer:

The attributes should match, not just be similar.
Also the Cortex-A9 only supports WB/WA.  From memory WB/nWA will get treated as WB/WA.  
Any WT regions get treated as non-cacheable.

 

ortant; text-shadow: rgba(0, 0, 0, 0.00392157) 1px 1px 1px !important; background: rgb(249, 249, 249);"   >ortant; text-shadow: rgba(0, 0, 0, 0.00392157) 1px 1px 1px !important;"   >[0]ortant; text-shadow: rgba(0, 0, 0, 0.00392157) 1px 1px 1px !important;"   >IRGN[1]ortant; text-shadow: rgba(0, 0, 0, 0.00392157) 1px 1px 1px !important;"   >
Indicates inner cacheability for the translation table walk:
IRGN[1], IRGN[0]
00 = Non-cacheable
01 = Write-Back Write-Allocate
10 = Write-Through, no allocate on write
11 = Write-Back no allocate on write.
Page table walks do look-ups in the data cache only in write-back. Write-Through is treated as non-cacheable.