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: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Tue, 16 Jul 2002 12:36:24 +0200 (MET DST)
Cc: linux-mips@oss.sgi.com
In-reply-to: <3D33F38A.1866E8BB@niisi.msk.ru>
Organization: Technical University of Gdansk
Sender: owner-linux-mips@oss.sgi.com
On Tue, 16 Jul 2002, Gleb O. Raiko wrote:

> In two words, it's unclear when there are no fills. Too much situations,
> additional stall condition (which may break spec anyway). I can't

 The cache logic somehow must know a fill is in progress.  Or at least
that it starts or finishes.  Another latch may store the state.

> present full explanation, sorry. You have to believe. :-)

 You don't have to convince me broken hardware is out there.  I am simply
trying to emphasize there is still some demand on good hardware, even if
marginally more expensive.

> BTW, I reread my R3081 HW Manual and found two intresting places about
> cache operation:
> 
> "These mechanisms [cache sizing, cache flushing] are enabled through the
> use of the ?IsC? (Isolate Cache) and SwC (Swap Cache) bits of the status
> register, which resides in the on-chip System Control Co-Processor
> (CP0). Instructions which immediately precede and succeed these
> operations must not be cacheable, so that the actual swapping/isolation
> of the cache does not disrupt operation."

 So someone will need to code a set of cache handling functions with a
workaround for this deficiency if we are to support a system with this CPU
as it appears Linux-capable.

 Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +



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