DEC 3000 (alpha) faultfinding

[Peter Coghlan]

Hi Maciej,

>
> "DEC 3000 Models 600/600S AXP and 800/800S AXP Service Information",
> Order Number: EK-FLSPC-SV. A01 (flspcsva.pdf) seems to indicate on page
> 2-2 that the SROM console jumper is one in position 0 among the SROM
> jumpers whose location is shown in the figure on that page.  I have
> checked my /700 (which is the same as the /600 except for a faster CPU)
> and this is also marked J8 on the PCB.
>

Many thanks for the pointer to EK-FLSPC-SV - I had not come across this
manual and it contains lots of useful information that is not in EK-D3SYS-PM.
I have some reading to do.  Interestingly, there are significant differences
in the descriptions of the diagnostic LED codes between the two manuals and
neither of them seems to describe exactly what I am seeing.

J8 (position 0) is where the jumper already is on both my 3000 600 machines.
It is possible that this is where it normally is, however, it is also possible
that I moved it there some time ago in an attempt to diagnose the problem and
I have since forgotten.  Which position is the jumper at in your system?
Anyway, you spurred me on to try moving it to some of the other positions.
When I place it at J3 (position 5), I get this:

DEC 3000 - M600 SROM 6.1
Mfg Test
ff.fd.fb.f0.
MCRstat 11111111.808011c0
bnkSize 00000300.00000c01
memSize 000000c0.000000c0

        memTest (no-cache)
        LongWord Memory Test

....done.
....done.
....done.

The last line repeats approximately every minute or so, possibly indefinately.

However, when I place the jumper at J2 (position 6), I get this:

DEC 3000 - M600 SROM 6.1
Mfg Test
ff.fd.fb.f0.
MCRstat 11111111.808011c0
bnkSize 00000300.00000c01
memSize 000000c0.000000c0

        memTestCacheOn
        LongWord Memory Test

address:0bf7dad8 wrote:ffffffff read:ffffddee
address:0bf7da58 wrote:ffffffff read:ffffddee
address:0bf7d8d8 wrote:ffffffff read:ffffddee
address:0bf7d858 wrote:ffffffff read:ffffddee
address:0bf7d2d8 wrote:ffffffff read:ffffddee
address:0bf7d258 wrote:ffffffff read:ffffddee
address:0bf7d0d8 wrote:ffffffff read:ffffddee

... followed by many many similar lines.  It looks like I have cache problems.
Maybe there is a way to disable the various caches and see if it works then.
This reminds me of my Alphaserver 1000A machines and their cache failures :-(

>
>> The 600 machines have a socketed 27C512 EPROM.  I assume this must be the SROM
>> (although I can't see what is serial about it) as the machines fail to update
>> the diagnostic LEDs or write to the mini console if it is removed.  I dumped
>> the two EPROMs and compared them and they are identical.  However, I can't see
>> any ASCII strings in them.  Perhaps the bits are not used in the standard
>> order?  The manual suggests that there are 8 different 8KB SROM images present
>> and those other than the "standard" one may be used for testing and diagnostics
>> by setting jumpers. Unfortunatly, there is no further information about these
>> images.
>
> The location of the SROM chip is also shown in the figure on page 2-2.
>

This show the location of the 27C512 EPROM in my systems so I guess it must be
the SROM.

>
>> The format of the headers in the SYSROM and IOROM do not exactly match the
>> format given in the manual but they are "close".  I wonder if this might
>> be my problem or if the manual is incorrect.  If anyone else has a 3000 600,
>> could they take a peek at their SYSROM and maybe we could compare notes?
>
> I could check my /700 with SRM.  What would you like me to look at?
>

Thanks but in light of my cache problems, it looks like I need to deal with
those first.  Perhaps the SYSROM is getting copied into main memory but when
the in-memory copy is read for execution, garbage is returned due to the cache
errors, leading to the system hanging with F0 on the diagnostic LEDs?  However,
according to one of the manuals (but not the other!), cache errors should have
been detected before the LEDs counted down as far as F0.

>
> Hope this helps.  Good luck with your fault debugging.
>

It was very helpful.  Many thanks.

Regards,
Peter Coghlan.

>
>  Maciej
>