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.