Subject: Re: Anyone running a Sparc5/170 ??
To: None <fair@clock.org, mcguire@neurotica.com>
From: George Robbins <grr@shandakor.tharsis.com>
List: port-sparc
Date: 07/01/1997 19:23:41
> From: Dave McGuire <mcguire@neurotica.com>
> To: "Erik E. Fair" (Time Keeper) <fair@clock.org>
> Subject: Re: Anyone running a Sparc5/170 ??
> 
> On July 1, you wrote:
> > The problem, I gather, is that the microSPARC II chips clocked faster than
> > 150 MHz (from Fujitsu) have some potentially incompatible changes to them
> > that we will need to divine and support in order to use those machines. Is
> > this an accurate assessment?
> 
>   The 5/170 appears to have a large external cache, as well.  That
> might be where things are blowing up.

Assuming that he 5/170 is basically a Sun-labeled TurboSPARC, the CPU
has a control register bit that addresses "Swift Compatibility Mode",
aka MicroSPARC.  It's not clear exactly what all this entails there
are a number of differences include the external cache, copyback vs.
write-thru caching, cache flush instructions and of course *BUGS* of
which the Swift has many.

You might want to review the options provided in the prom monitor to
see if there's any way to enable/disable Swift vs. Native mode, or
some special forth words to that effect.  The sample diagnostic output
in the TurboSparc documents suggests this is a possibility, but don't
say anything explicit.

The proximate error is that the CPU is taking what is apparently a
trap type defined in the v8 spec, but not seen on the other supported
Sparc systems, something that *may* be conditional on this compatibility
mode bit.

						George