Re: CONFIG_MIPS_UNCACHED

[Jun Sun <jsun@mvista.com>]

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