linux-mips
[Top] [All Lists]

Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96

To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Thu, 11 Jul 2002 13:12:47 +0200
Cc: Carsten Langgaard <carstenl@mips.com>, Jon Burgess <Jon_Burgess@eur.3com.com>, linux-mips@oss.sgi.com
In-reply-to: <3D2D58A6.2E5D9695@niisi.msk.ru>; from raiko@niisi.msk.ru on Thu, Jul 11, 2002 at 02:06:30PM +0400
References: <80256BF2.004ECBE6.00@notesmta.eur.3com.com> <20020711021554.A3207@dea.linux-mips.net> <3D2D465C.FA06D50A@niisi.msk.ru> <3D2D4D83.B2694DF1@mips.com> <3D2D58A6.2E5D9695@niisi.msk.ru>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5.1i
On Thu, Jul 11, 2002 at 02:06:30PM +0400, Gleb O. Raiko wrote:

> > > Unfortunately, it's required by manuals for some processors. As I know,
> > > IDT HW manuals clearly state cache flush routines must operate from
> > > uncached code and must access uncached data only. Examples are R30x1 CPU
> > > series.
> > 
> > Yes, that's true.
> > But that code belongs in the R30xx specific cache routines, not in the
> > MIPS32 cache routines.
> 
> I don't wonder if other IDT CPUs also require this, including those that
> conform MIPS32.
> Basically, requirement of uncached run makes hadrware logic much simpler
> and allows  to save silicon a bit.

The R3000 cache manipulation mechanism is implemented by giving magic
meaning to store instruction while the isolate cache and swap cache bits
are in use.  By their very implementation they're both incompatible with
normal operation of caches and therefore can only be used from uncached
space.

For most part of it the situation for R4000 class CPUs is easier; a cache
instruction either hits or fails.  The only problem I could imagine an
access conflict in the i-cache when both normal instruction fetch and the
cache instruction are going to operate on the i-cache and that sounds like
a less likely problem to me.

Of course not having read the RTL of all CPUs there is a bit of speculation
here :)

  Ralf


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