[rescue] Hanging with NVRAM in?

[Jonathan Chapman]

Using a "too new" M48T02/M48T08 will as well, though that does not seem to be the case here.

Thanks,
Jonathan

On Thursday, November 20th, 2025 at 11:04, Patrick Finnegan via rescue <rescue at sunhelp.org> wrote:

> On Thu, Nov 20, 2025, 07:44 Mouse via rescue <rescue at sunhelp.org> wrote:
>
>> I've got a bunch of SLC and ELC boards, saved from back in the day,
>> with a handful of the connector boards they plug into.
>>
>> I got them out recently because of the "SPARCstation 1 boot woes"
>> thread. I found I had one MK48T02B, which of course had a long-dead
>> battery. So I moved it from machine to machine. All worked, except of
>> course that the dead battery meant it didn't retain anything over a
>> power-off.
>>
>> Yesterday, I found two more ELC boards, so I tried to set them up.
>>
>> And I saw some very peculiar behaviour.
>>
>> With the NVRAM socket empty, the boards power up and go through
>> selftest just fine - well, as fine as can be expected; they complain
>> about the NVRAM not retaining data, but that's no surprise when there
>> isn't any NVRAM there. They even boot diskfully, albeit with a
>> 00:00:00:00:00:00 MAC.
>>
>> But with the NVRAM in the socket? They don't print any of the selftest
>> messages on power-up, not even the first few that they print even with
>> no RAM installed. (I didn't wait long - several seconds - but the
>> first messages are normally close enough to instant that at the human
>> layer I can't see any delay.)
>>
>> So I tried the other boards, the ones that worked (with the same
>> MK48T02B) before. Same syndrome.
>>
>> But pull the chip, and they go back to "working".
>>
>> Anyone have any idea what might be behind this?
>
> A completely dead battery can cause this, along with an otherwise damaged nvram chip.
>
> Patrick Finnegan
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sunhelp.org/pipermail/rescue_sunhelp.org/attachments/20251120/07598233/attachment.html>