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