> > On 02 May 2016 at 22:56 "Maciej W. Rozycki" <[email protected]> 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 >
