When writing code, for example during relocation, we ensure that the icache has a coherent view of the new instructions with a call to flush_cache(). This handles the bulk of the work to ensure the new instructions will execute as expected, however it does not ensure that the CPU pipeline doesn't already contain instructions taken from a stale view of the affected memory. This could theoretically be a problem for relocation, but in practice typically isn't because we sync caches for enough code after the entry point of the newly written code that by the time the CPU pipeline might possibly fetch any of it we'll have long ago written it back & invalidated any stale icache entries. This is however a problem for shorter regions of code. In preparation for later patches which write shorter segments of code, ensure any instruction hazards are cleared by flush_cache() by introducing & using a new instruction_hazard_barrier() function which makes use of the jr.hb instruction to clear the hazard. Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Cc: u-boot@lists.denx.demaster
parent
219c2db384
commit
d8b326976a
Loading…
Reference in new issue