[U-Boot] [PATCH 1/9] arm926ej-s: Invalidate instruction cache in flush_cache

arden jay arden.jay at gmail.com
Mon Mar 21 15:14:09 CET 2011


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 <aneesh at 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<mspang at 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<mspang at 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 at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>
>>
>>
>



-- 
cheers,
jay


More information about the U-Boot mailing list