Re: CONFIG_MIPS_UNCACHED

[Jun Sun <jsun@mvista.com>]

Pete Popov wrote:
> 
> Ralf Baechle wrote:
> >
> > On Wed, Jan 24, 2001 at 12:10:32PM -0800, Jun Sun wrote:
> >
> > > 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.
> >
> > If you want to be strictly correct you have to execute the code that
> > disables caching of KSEG0 in uncached space like KSEG1, then flush the
> > caches before you can resume execution in KSEG0.  Otherwise you might
> > end up with dirty d-caches which when flushed will overwrite more
> > uptodate data in memory.  The window is very small but yet exists if
> > things are just right.
> 
> The EV96100 running Galileo's pmon exhibits exactly this symptom.  Pmon
> apparently sets up kseg0 to cache coherency 3;  but eventhough the
> kernel also sets it to 3, if I don't flush the caches first I end up
> with overwritten data.  A different version of pmon that I have sets
> kseg0 to 1 (writethrough). Changing that to 3 isn't a problem -- or at
> least it doesn't seem to cause any problems.
> 

I don't think it is the same problem.

Here is the simplified view of the process, if I understand Pete correctly:

1. pmon sets kseg0 to 3 (cache enabled)
2. kernel starts in KSEG0 
3. kernel sets kseg0 to 3 again (essentially keeps the same config value)
4. kernel flushes cache
  ===> Q: data corruption or not?

I think the data should be consistent.  Otherwise it looks like a CPU bug to
me.

What ralf described is something like the following:

1. pmon sets kseg0 to 3 (KSEG0 cache enabled)
2. kernel starts in KSEG0 
3. kernel sets kseg0 to 2 (disable kseg0 cache)
4. kernel flushes cache
  ===> Q: data corruption or not?  YES, data can be corrupted!

Jun