On Wed 8 Aug 2007 02:50, Wolfgang Denk pondered:
In message 1186552257.15798.6.camel@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@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