22 Oct
2023
22 Oct
'23
12:36 p.m.
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...