Subject: Re: Anyone running a Sparc5/170 ??
To: None <email@example.com, firstname.lastname@example.org>
From: George Robbins <email@example.com>
Date: 07/01/1997 19:23:41
> From: Dave McGuire <firstname.lastname@example.org>
> To: "Erik E. Fair" (Time Keeper) <email@example.com>
> 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