-----Original Message-----
From: cctech [mailto:cctech-bounces at
classiccmp.org] On Behalf Of Maciej
W. Rozycki
Sent: 02 May 2016 08:14
To: Robert Jarratt <robert.jarratt at ntlworld.com>
Cc: 'General Discussion: On-Topic Posts' <cctech at classiccmp.org>
Subject: RE: AlphaStation 200 NVRAM Problem
On Sun, 1 May 2016, Robert Jarratt wrote:
Any ideas what it might be?
I can't help with the chip, except that the manual states it's a 64-Kbyte
part.
But something has struck me:
"When the SROM code has completed its tasks, it normally loads the DROM
code and turns control over to it. The SROM checks to see if the DROM
contains the proper header and that the checksum is correct. If either
check
fails, the SROM code reads a location in the TOY
NVRAM. The location
indicates which console firmware (the SRM or the ARC) should be loaded."
-- I think it's highly unlikely that DROM is corrupted *and* it passes the
checksum test *and* corrupt DROM code works well enough to progress
through any POST stages at all (i.e. change LEDs to anything beyond what
SROM has left). So I wonder what else might be causing the symptoms you
have seen. SROM console output undoubtedly might help here as DROM
might be reporting what it does not like, about NVRAM presumably.
I suppose I should find or construct a diagnostic port adapter. I suppose I
am slightly put off by the effort needed to make one as I don't have the
components needed to hand. I may just have to bite this bullet.
One possibility I have in mind is it's something peculiar about DRAM.
As you may have been aware DROM code isn't run directly, it's loaded by
SROM into DRAM. If it fails a specific bit pattern at a specific location
for
some reason, then you might see symptoms like these.
So shuffling DRAM
modules might change something here.
I will give this a go, but it seems unlikely as the machine is able to run
VMS, and I assume it must be passing at least some basic memory tests.
Other than that maybe it's NVRAM after all. But what could it be then
that
did not show up in your testing? Could it be that the
settings and
environment variables stored there are protected with a checksum (or a
signature) which happened to be correct for the random contents after
power was restored and that in turn confused DROM diagnostics? Can you
wipe NVRAM with your program, reinstall the DROM chip and see if the error
returns?
This thought has crossed my mind. However, since I had to change the battery
that backs up the NVRAM in any case, then surely the memory would have been
zeroed? This NVRAM is battery backed, right? The NVRAM does contain data, I
have verified this with my program, so something is repopulating it after
the battery has been changed. I am slightly reluctant to zero the memory on
purpose in case I can no longer boot the machine (I would save the contents
before zeroing of course).
I start running out of ideas, and sorry to have misled you into thinking
it
might be DROM contents which are wrong -- given the
checksum protection I
think it's highly unlikely after all.
Not to worry, your thoughts and suggestions have helped hugely.
Thanks again
Rob