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

How to do cache invalid on Cortex-A53?

hi,

     I'm studying Cortex-A53 cache process. I run the following cache invalid program, but the result is cache not invalid.

     Could you give me any suggestion about cache invalid? Thanks!

     The program is:

     mov x0, #0xffff
     adr x1, label
     str x0, [x1]
     dsb sy
     isb
     ...enable MMU and D-cache
     mov x0, #0xaa55
     adr x1, label
     str x0, [x1]
     dsb sy
     isb
     bl cache_invalid_all (or use "dc ivac, x1")
     isb
     adr x1, label
     ldr x0, [x1]  ==> The "X0" value is 0xaa55, the cache invalid seems not work??

     .align 6
label:
    .quad 0
  • Nothing is stopping the CPU from writing the cache line back to memory after the initial store and before the invalidate. Caches can evict data and write it back to main memory at any time after the store has happened, so your experiment is based on an incorrect assumption and not guaranteed to return the result you expect.

    HTH,
    Pete

  • Hi Peter,

         Thanks for your response.

         I'm still a little confused.

         There are only "dsb, isb" between init store and invalid cache.

         Memory access instructions can cause cache evict data.    

         Can "dsb/isb" also cause cache evict data and write it back to main memory?

        Even if no instruction between store and invalid cache, can caches evict data and write back to memory?

  • A cache can decide to evict data at any point in time, for any reason - there doesn't need to be an instruction to trigger the eviction. It would even be architecturally correct for a cache not to cache the result at all and just write the result directly to memory, or cache the result AND write the result directly to memory.

    FWIW I'm not saying that is what is happening here - a lot depends on the cache design - but these types of experiments are notoriously hard to design as caches are designed to run on auto-pilot without much programmer intervention.

    In your case I would check you page table settings to make sure that the pages are definitely set up as cached, and that the cache is not in write though mode.

  • Hi Peter,

         My page table setting is:

          the page table content of "label" is: 0x00400000(High) 0x04015703(Low), and the MAIR_EL3 is 0x4ff.

          Thanks for your attention!

  • Just adding to Pete's post....

    The specific bit of the Architecture Reference Manual which states this is:

    D3.4.1 General behavior of the caches
    ...
    The following principles apply to the behavior of caches:
    ...
    * Any memory location is not guaranteed to remain incoherent with the rest of memory.