• State Accepted Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 351 subscribers
  • Views 1894 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

cache contents miss fit with main tlb

WatterCutter

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.

Parents
  • 0 in reply to Martin Weidmann

    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 

Reply
  • 0 in reply to Martin Weidmann

    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 

Children
  • +1 Arm Employee Badge in reply to WatterCutter

    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.

  • 0 in reply to Martin Weidmann

    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.