Fired up my three PowerLites...all three need nvram batteries, no
surprise. One has a failing display, one has a dead display or an issue
with power but they all at least boot up.
Bill
On Sun, Oct 22, 2023, 3:36 PM erik--- via cctalk <cctalk(a)classiccmp.org>
wrote:
Thanks Jonathan for the offer. Meanwhile X-rayed the
1643 as well and
connected a really big battery. Here again: Had to start the oscillator
before the UltraBook passed the POST and turned on the display - it is up
and running again now - UltraBook and UltraBook IIi restored. So my final
report:
(1) Failing UltraBooks and UltraBooks IIi can get a "new" NVRAM, but need
them erazed and the oscillator started. After that, they power up again.
(2) The procedure given in the Sun NVRAM-FAQ for using the OpenFirmware to
set Machine Type 0x80, MAC, HostID and checksum works as given there (using
the mkp command). This information goes into NVRAM adresses 0x1FD9 and
following.
(3) Also OpenBoot and the command idprom@ can be used to read the
information (again according to the table in the FAQ) from NVRAM.
(4) real-machine-type and update-system-idprom are not implemented in the
UltraBooks and they are not necessary as well (information is written to
the NVRAM immeiately with the mkp command).
(5) During booting, Solaris may complain on a wrong date format in the
NVRAM - but this message goes away after time was set using the OS's date
command.
(6) The contents of the NVRAM for lower addresses look different between
UltraBook and UltraBook IIi, so it does not make sense using NVRAM contents
from one type on the other one (boot order is at 0x2CB for both, but
TTY-settings differ).
(7) The Open-Firmware manual lists some interesting additional STOP
sequences on top of STOP-A which may be of help if encountering problems -
e.g. for resetting NVRAM or starting a Forth interpreter on TTYA for
debugging of hardware problems - see page 107 in 901-7042.
Happy computing and thanks to all who responded or participated in one way
or another...