AlphaStation 200 NVRAM Problem

[Maciej W. Rozycki]

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.

 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.

 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?

 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.

  Maciej