AlphaStation 200 NVRAM Problem

[Maciej W. Rozycki]

On Mon, 2 May 2016, Robert Jarratt wrote:

> >  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 don't think you can assume power-cycling NVRAM (which is effectively 
what you've done here by putting a new battery) will zero it.  It would if 
there was some kind of a reset signal asserted at poweron that would set 
the flip-flops to a known state.  But the KM6264B chip does not appear to 
have such a feature, nor an external reset input.  So we need to assume 
its contents are random after a powerup.  Have you ever used Sinclair ZX 
Spectrum?  It had its video adapter active from powerup and you could 
briefly see the random contents of video RAM on the screen.

 I understand your reluctance.  The NVRAM is indeed supposed to be backed 
with the same battery the RTC is.  There's just a slight chance the 
battery circuit is not operating correctly.  There's no battery status bit 
in the NVRAM, but there is one in the RTC.  You should be able to verify 
it with:

 >>> d -b pmem:1c0000e00 0d
 >>> e -b pmem:1c0000e20

this will read BQ4285 RTC chip's register D.  If this comes out as 80, 
then the battery is giving power to the chip.  If this is 00, then there 
is no battery power available.  Of course a broken PCB trace could make 
battery power reach one of the two chips only.

 BTW, does your SRM console have a TEST command?  If so, then have you 
tried it?  Of course it might want to call into DROM and thus fail rather 
spectacularly if it's absent, but chances are it might not and you may get 
useful output from it.

  Maciej