ons 2013-05-15 klockan 19:39 +0200 skrev Albert ARIBAUD:
> I understand all this, but what I am interested in is the root issue. > > IIUC, the problem is that some code is loaded in DDR, and the CPU is > about to jump to it, but its instruction cache is enabled so maybe some > instructions after 'go' will be (wrongly) fetched from I-cache instead > of being read from DDR (and fed into I-cache). Yes. > Nothing in this is ARMv7 specific; it could happen in an arm926ejs just > as well. It could happen on any CPU with distinct, non-consistent I- > and D- caches an enabled I-cache. Correct on all accounts. > So my suggestion is to implement the icache_flush in common/bmmt_cmd.c > as follows: > > ... > /* just about to 'go' */ > #if CONFIG_ARM > #if CONFIG_ICACHE > if (icache_status()) > invalidate_icache_all(); > #endif /* CONFIG_ICACHE */ > #endif /* CONFIG_ARM */ > /* now go */ This style is a nightmare for adding more arches needing this, but solves the problem today. But there is no CONFIG_ICACHE. In ARM there is CONFIG_SYS_ICACHE_OFF but it's not quite the same. >From what I can tell there is no need to theck icache_status(). It's always safe to call invalidate_icache_all(). So it's back to use the compiler define for ARMv7. > The only problem I see for now is that, while ARM has a default > icache_status(), apparently the targets that need the invalidate above > do not have their own version of icache_status(); they'll need to > provide one for this code to work. And also an invalidate_icache_all(). That only exists on armv7 today. m68k have icache_invalid() which seems to be the same. Regards Henrik _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
