[U-Boot-Users] [Patch] Disable icache before call the firstline of kernel in do_bootelf().

[Robin Getz]

On Wed 8 Aug 2007 02:50, Wolfgang Denk pondered:
> In message <1186552257.15798.6.camel at sevens.analog.com> you wrote:
> > On some architecture, it is not save to call the first line of kernel 
> > without disable the instruction cache. For do_bootm() path,
> architecture 
> > specific library code do_bootm_linux() can adress this issue, but 
> > do_bootelf() is common code. This patch disables icache before call
> kernel.
> > 
> > 
> > Signed-off-by: Sonic Zhang <sonic.zhang at gmail.com>
> 
> Did you test the impact of this change on all other architectures but
> the one you are talking about (without ever mentioning it)?
> 
> I don't think we want to do this in general. Please make  this code
> conditional.

I think it is reasonable/prudent to turn off cache in all situations, on all 
architectures.

As an application developer, I don't want an early TLB miss on any 
architecture to cause a vector back to U-Boot's cache handler (which may not 
be there anymore). I would expect to have to write my own, and set it up 
myself if I want to run with cache on.

Instruction and data caches in U-Boot are a great thing, since it decreases 
the time for a kernel or file system to be loaded, decompressed, but once 
U-Boot looses control (the jump to the unknown application), it shouldn't 
expect a return, or the hardware not to be changed by the app.

go, bootm, boote, etc - should flush & turn off cache before the jump to the 
application code (should also turn off what limited interrupts are enabled) 
to be safe.

It could be a fair comment to tell people to add "dcache off; icache off; 
boote" to their scripts, but this slows down boot, since you want the cache 
on while you are doing the elf relocations. What you might want is 
a  "relocate_elf; dcache off; icache off; go $(elf_entry)" which seems worse 
than just forcing it off in all situations. ?

-Robin