AlphaStation 200 NVRAM Problem

[Jarratt RMA]

> 
>     On 02 May 2016 at 22:56 "Maciej W. Rozycki" <macro at linux-mips.org> wrote:
> 
> 
>     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 did a test last night which failed, but realised I did it wrong. I am away
from home again now and will try that test again, plus the suggestions below.

Thanks

Rob


> 
> 
>     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
>