linux-mips
[Top] [All Lists]

Re: CONFIG_MIPS_UNCACHED

To: Pete Popov <ppopov@mvista.com>
Subject: Re: CONFIG_MIPS_UNCACHED
From: Jun Sun <jsun@mvista.com>
Date: Wed, 24 Jan 2001 12:10:32 -0800
Cc: Quinn Jensen <jensenq@Lineo.COM>, linux-mips@oss.sgi.com
References: <3A6E132B.9000103@Lineo.COM> <3A6E1977.2B18484D@mvista.com>
Sender: owner-linux-mips@oss.sgi.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

<Prev in Thread] Current Thread [Next in Thread>