3 May
2016
3 May
'16
2:14 p.m.
On 02 May 2016 at 22:56 "Maciej W. Rozycki" <macro at linux-mips.org>
wrote:
On Mon, 2 May 2016, Robert Jarratt wrote:
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
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). 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