Pete Popov wrote: > > 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. > It is really surprising to know this. It sounds like a CPU bug to me. Can some MIPS "gods" clarify if such a behaviour is a bug or allowed? BTW, the CPU in EV96100 is QED RM7000, I believe. Jun
