Quinn Jensen wrote: > > Ralf, > > On some machines with weird firmware (e.g. IDT 334 board) > the processor comes up with the cache already enabled for > kseg0. In this case, the set_cp0_config() call in mips32.c > to turn off the cache (gated by CONFIG_MIPS_UNCACHED) should > probably come after the first call to flush_cache_all(), > which is safer but still not totally safe, I suppose. > Or am I totally hosed trying to turn the kseg0 cache off > after it was once on? That's an issue not only when you're "turning off" the cache, but whenever you muck with the kseg0 cache coherency attribute. The Galileo EV96100, running Galileo's pmon, comes up with kseg0 set to 3, which is the default linux kseg0 cache coherency attribute. However, calling set_cp0_config() without first flushing the cache destroys some data, eventhough the same exact kseg0 attribute is set. I think a complete cache flush is in order before calling set_cp0_config() and that's a change we should make for all cpus. Pete
