since I did:
1、set I and C bit in SCTLR_EL3
2、enable MMU
3、setup page table
4、change memory attr of address space 0x30000000-0x3020000000 (sram) as inner shareable|write back|r/w allocate
5、read and write 0x30000000 more than 2 times
I found that：
1、L1 cache contes only contains addresses related with page table （0xFXXXXXXX-)
2、main TLB contains addresses related with both page table and 0x30000000
my question is:
1、does this mean no data from 0x30000000 was caches ?
2、what's the reason cause this?
thanks.
WatterCutter said:2、enable MMU 3、setup page table 4、change memory attr of address space 0x30000000-0x3020000000 (sram) as inner shareable|write back|r/w allocate
This might just be how you described the steps, but you really need to have done (3) before (2).
In step (4), did you invalidate the TLB after changing the translation table entry? (The Arm Arm has an example sequences in K13.5.3 - TLB maintenance instructions and barriers).
What did the translation table entries for 0x30000000 say before you modified them in step (4)?
If you create the translations table with 0x30000000 already marked as IS/WB/RW before enabling the MMU, do you then see 0x30000000 in the cache after (5)?
My suspicion is that you're not invalidating the TLBs in step (4), and thus the MMU is using a stale translation
thanks,
the actual steps are:
1、disable MMU (set I/C/M bits in SCTLR_EL3 as 0)
2、setup page table (whole addr space as Device-nGnRnE)
3、enable MMU (set I/C/M bits in SCTLR_EL3 as 1)
4、change attr of 0x30000000-0x30200000 to NORMAL/IS/WT/RW (add invlidating operation as you recommand)
5、read and write 0x30000000
what I see:
1、in main tlb, addr related with 0x30000000 cleaned (only reamin tlb related with page table area) after (4)
2、in main tlb, addr related with 0x30000000 appeared again after (5)， but no addr related with 0x30000000 showd in L1 data content
Ok, that makes more sense.
In step (2), the initial translation table should at least mark where you're executing from as Normal. Strictly speaking, it is not legal to execute instructions from regions marked as Device, and we usually recommend that all Device regions are also marked as not executable (XN=1) to avoid potential speculative instruction fetches from Device regions. See here https://developer.arm.com/documentation/102376/0200/Device-memory
In step (4), you wrote "NORMAL/IS/WT/RW". Many Arm cores don't support Write-Through (WT) and will treat WT regions as effectively Non-cacheable. You'll need to check the TRM for the processor your using to know whether that's true for yours. But try using write-back (WB) instead,
Another potential gotcha is setting different inner vs outer cache-ability settings.
It seems to be useful(just considering the time consumed by the processor), thank you very much, more tests are being done to ensure the function.