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
The SMC instruction is a call to the "secure world" software, rather than a native ARM instruction, so whether cache invalidation is supported would be a question for your secure software supplier. In general it isn't possible for non-secure software to invalidate the entire cache (the cache may contain secure data, and that would be a destructive operation); clean-and-invalidate is generally provided as an alternative, but what is available will depend on your software stack.
HTH, Pete
What I understand from your comment that clean-and-invalidate is possible ONLY if "secure software" provide a mechanism/instructions as it was provided in case of invalidate. Also if i am not wrong that we can not clean-and-invalidate L2 (Cortex A8) as we do for L1.
Architecturally you can perform cache maintenance directly from the non-secure world, but they can only impact non-secure cache line entries in the cache. If you want to ensure the entire cache is cleaned and invalidated then that operation must be performed from the secure world as it may impact secure lines.
Note that there are some errata which impact some revisions of the Cortex-A8 which require some cache maintenance operations to be performed from the secure world; TI should be able to provide you with the relevant errata notices for the version of the Cortex-A8 present in your chipset.
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