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

Michael Spang mspang at csclub.uwaterloo.ca
Mon Jul 29 14:57:53 CEST 2013


Albert,

That's not a correct characterization of the bug.

The incoherent cache lines are from before the relocation stage. If
U-Boot is relocating from RAM, and later copies the OS there without
invalidating those lines, then that's a bug in U-Boot.

Michael

On Mon, Jul 29, 2013 at 3:19 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> (although this patch is more than two *years* old, it never got properly
> answered to. I am doing so here to make sure future readers know why it
> was not applied and won't be.)
>
> Hi Michael,
>
> On Thu, 17 Mar 2011 15:46:55 -0400, Michael Spang
> <mspang at csclub.uwaterloo.ca> wrote:
>
>> 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);
>
> This patch has obviously not been applied, and won't be, because of
> two reasons: i) overwriting part of U-Boot when loading the kernel
> is a bug which should not be papered over, and ii) if we had to do this
> anyway, the right place to do it would have been where the issue might
> occur, that is, in the OS boot sequence, not in the cache handling
> functions.
>
> Apologies for not properly answering in due time.
>
> Amicalement,
> --
> Albert.


More information about the U-Boot mailing list