Hi,
I am working on DM37xevm platform and already invalidate the L2 cache (256KB) using the code
asm volatile moveq r12, #0x1");
asm volatile ("smc #1"); // Got from Technical Reference manual
I am particularly interested to flush the L2 cache. No guidelines are given in TRM for flushing. Is it possible to flush the L2 cache.
Regards
Hello,
Can I assume that with cortex A8 cache invalidate/flush is used only with L1 ?I have some 2 implementation of this routines, one is called L1 and the other L2C-310.
I am just not sure if using L1 will be goond enough, or wether cortex a8 internal L2 still need to be flushed/invalidate.
Thank you!
Ran
Cortex-A8 doesn't need the L2C-310 (or at least I've never seen anyone use a Cortex-A8 with one. It'd be L3 in most systems if they did). You can invalidate the built-in L2 just fine with the caveats Peter pointed out with regards to some errata that prevent you from doing it purely in the non-secure world on certain revisions (the Cortex-A8 errata aren't on Infocenter, but TI can provide them to you if you're a customer - a good number of them will be in the DM37x errata documentation, though).
How and when you do it depends on some things which are well documented in the ARM Architecture and Cortex-A8 TRM (Point of Unification, Point of Coherency, whether L2 is Inner or Outer Cacheable, etc.). You should look up the Cache Level ID register (CLIDR)
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Chdfegfe.html
.. and obviously some cache operations take a "Level" (which is the one in the CLIDR):
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Babhejba.html#Chdijcbh
Other cache operations only specify PoU or PoC, and which you use depends on the use case. Synchronizing the MMU, Instruction and Data caches to see a coherent view of memory, you use PoU (CLIDR.LoU is 0x1 which means it will go as far as L2). Anything else (making it visible to the rest of the system), you use PoC (CLIDR.LoC is 0x2 which means it will go as far as L3. Just add 1. You can tell which level has caches in the CLn fields, so if L3 is the PoC and there's a 0 in CL3, you get the drift..)
So, if you want to clean and invalidate the entire L2 by specifying the level and set/way iteratively, or just ranges of addresses by specifying a 'point of', you can do so, caveats notwithstanding.
What TI have done is provided a way to work around any erratum that affects the process by asking secure software to do it on behalf of non-secure software (they should also be able to tell you how that works, too, if you're a customer, or you can find it on one of their Wikis sometimes). You may not be affected by it depending on the revision of the Cortex-A8, which is in the MIDR register.
Ta,
Matt