Hi Michael, Thanks, it is the key point: "The problem is that it hits, but returns the wrong instructions."
Hi Aneesh, Thanks for your sharing, it makes sense to check that way. 2011/3/21 Aneesh V <ane...@ti.com>: > Hi Arden, > > On Sunday 20 March 2011 08:00 AM, arden jay wrote: >> >> Hi Michael, >> Curiously, have any idea how to test cache stuff? > > Recently I did some cache testing. Here is the technique I used for > data-cache: > > To test flush: > * Write a known pattern to a region of memory > * Flush the region > * Invalidate the region > * Read back the region and see if you get the original pattern. If the > flush was effective you will see the original data. > > To test Invalidate: > * Write a known pattern to a region of memory > * Invalidate the region immediately > * Read back the region and see if you get the original pattern. You > should *not* be seeing the expected pattern for the entire region if > the invalidate was successful. > > Similar tests can be done for the I-cache, but maybe a little more > tedious. > > I agree that these tests may not be 100% fool-proof - for instance what > if both invalidate and flush didn't work in the first case. But these > should at least catch very obvious errors and can be used in > combination with other techniques to make sure that your cache > operations are indeed working. > > Additionally, there was a JTAG debugger technique that I found quite > useful. If your processor supports a technique called DAP(Debug Access > Port or Dual Access Port, I am not sure) then a debugger like > Lauterbach can view memory in two modes, one the normal or CPU mode and > the other DAP mode. In normal mode the memory is dumped as if it is > viewed from the CPU, so it goes through the cache and you see the cache > contents if the area in question is in cache. In DAP mode the > real memory contents are dumped. Comparing these two you can see > whether cache and memory are coherent for a given area. It worked quite > well with Lauterbach and OMAP4. > > br, > Aneesh > >> >> 2011/3/18 Michael Spang<msp...@csclub.uwaterloo.ca>: >>> >>> If U-Boot is loaded from RAM and the OS is loaded into an overlapping >>> region, the instruction cache is not coherent when that OS is started. >>> We must therefore invalidate the instruction cache in addition to >>> cleaning the data cache. >>> >>> Signed-off-by: Michael Spang<msp...@csclub.uwaterloo.ca> >>> --- >>> arch/arm/lib/cache.c | 2 ++ >>> 1 files changed, 2 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c >>> index 30686fe..047786a 100644 >>> --- a/arch/arm/lib/cache.c >>> +++ b/arch/arm/lib/cache.c >>> @@ -37,6 +37,8 @@ void flush_cache (unsigned long dummy1, unsigned long >>> dummy2) >>> asm("0: mrc p15, 0, r15, c7, c10, 3\n\t" "bne 0b\n" : : : >>> "memory"); >>> /* disable write buffer as well (page 2-22) */ >>> asm("mcr p15, 0, %0, c7, c10, 4" : : "r" (0)); >>> + /* invalidate icache for coherence with cleaned dcache */ >>> + asm("mcr p15, 0, %0, c7, c5, 0" : : "r" (0)); >>> #endif >>> #ifdef CONFIG_OMAP34XX >>> void v7_flush_cache_all(void); >>> -- >>> 1.7.2.3 >>> >>> _______________________________________________ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> http://lists.denx.de/mailman/listinfo/u-boot >>> >> >> >> > -- cheers, jay _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot