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...

Reply via email to