Re: [ProgSoc] What to do with the SparcCenter2000E...

[<telford@nospam.progsoc.uts.edu.au>]

On Wed, Mar 21, 2001 at 05:01:25PM +1100, Matt wrote:
> On Wed, Mar 21, 2001 at 04:52:12PM +1100, miKe wrote:
> 
> > I think the main problem is they can't even turn it on cause Telford
> > lost the keys... I've tried sourcing some but nobody here seems to
> > have any.
> 
> i have a source of key(s). but no need to worry in the near future
> about that, we hotwired the thing. we do however seem to have either a
> backplane problem or both the CARBs are screwed (the backplane
> controller arbiters).

I think that the CARBs are on that little board that goes in the front
and we have two of those. Did we try them both that night (I think we did).
Seems unlikely they are both blown (then again this stuff did come from
Suns basement). I thought that miKe got as far as at least booting
something so there is probably something we are doing wrong.

I found out what a JTAG error is all about -- the ``Joint Test Action Group''
specified a serial bus protocol for clocking a test signal into chips
allowing for a test pattern that checks all the connections on all the
circuit boards (or at least all the ones between JTAG compatible chips)
and these machines have a self-diagnosis mode that uses the JTAG for this
purpose.

The error either means that the JTAG system was not working at all or that
it did run the JTAG test and some connection somewhere came out wrong.

> we are in search of a SC2000 FE manual, but i
> have been told that it is 3 pages long and mostly content free because
> it mainly consists of text like "if this doesnt work return the parts
> so they can be fixed"

There is a facility for an external JTAG connector to allow you to scan
all the chips and all the circuits through a PC with a suitable port.
However, although the JTAG commands are well documented, the bit patterns
that you get back don't mean much unless you know what all circuit
connections in the machine. No doubt Sun has diagnosis software somewhere
that already has complete bit patterns and can isolate the bad connection
very rapidly. Also no doubt we are not going to get hold of such a thing.

> some of the chips may have been static fried in
> transport *shrug* we dont know yet. im going to try and get the
> hardware fault history for the machine. in the mean time, hurry up and
> wait.

Well we tried a few CPU boards and we can have a go with a few more,
I can't believe that they were all static fried -- that is just so unlikely.
As for the backplane, there is nothing to fry. Also, the SPARC cpu did get
far enough to actually print an error message so at least the CPU modules
must be OK, and it must be able to read some sort of program out of the PROM.

That just leaves those little CARB boards and we tried two of those...

We can pull the backplane out of the other machine and give that a go
but it is a fair bit of work.

	- Tel

-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.