Hi there, in the last weeks my last two working UltraBooks died. Today I investigated the problem and obviously in these RDI made notebooks, the NVRAMs not only contain the boot information, the host ID and the MAC address but also the hardware configuration. Hence: Once the NVRAM is completeley dead, absent or replaced, the unit will not start up any more - it gets stuck in the power on test BEFORE the screen shows any information. Do anyone out there have got UltraBooks or UltraBooks IIi up and running? Would highly be interested in a dump of the NVRAM/Timekeeper!!! The failed first generation UltraBook are (DS1643 NVRAM): (*) U20-14-9-512P with three (!!) hard drives, no battery port (*) U20-14-3-128B two hard drives, battery port And my beloved UltraBook IIi (TimeKeeper DS1553-070) (*) U40-14-1X-1024C one harddrive, battery port and creator graphics. Reply here or PM erik(a)baigar.de, Thanks ''~`` ( o o ) +--------------------------.oooO--(_)--Oooo.-------------------------+ | Dr. Erik Baigar Inertial Navigation & | | Salzstrasse 1 .oooO Vintage Computer | | D87616 Marktoberdorf ( ) Oooo. Hobbyist / Physicist | | erik(a)baigar.de +------\ (----( )---------------------------+ | www.baigar.de | \_) ) / +----------------------+ (_/ So advice to all owners: Backup your NVRAM contents and I'd be more than happy to get in touch with you! Not affected seem to be the PrecisionBooks (e.g. H16-12-8-512L2, two hard- drives and battery port) as they do not contain an NVRAM/TimeKeeper.

The more are joining the higher the probability, that we will be able to solve it somehow ;-) What kind of UltraBook do you have got?

Did some experiments in removing/swapping NVRAMs and none of my UltraBooks is reaching the OpenFirmware or even turning on the backlight/LCD, so I have no way of trying to read the NVRAM contents from there :-( Symptoms (i.e. behaviour of the LCD display) of the UltraBooks differ with contents of NVRAM or if there is no NVRAM at all. So without some known-valid NVRAM contents I fear I am lost :-( Symtpoms I see: Power symbols coming up always then (a) only tock-tock from speaker (b) blank, only the inverse A flashing several times, later a single time again and then blank forever (c) heart beat and speaker flashing, later the inverse A coming on as well. Can anyone out there at least tell me what their LCDis showing during startup? I will archive the contents of the NVRAMs as they are now although they are probably not of much use...

Now the good news is, I can probably make replacements for the DS1553W. I already have a prototype replacement for the DS1643

Speaking of dumping... Is it possible to read a Dallas DS1643 in programmer? That's what's in my Ultrabook. I just tried with a Topmax II that supports it and I get all zeros. :(

Hi Jonathan, thanks for your thoughs. I am still using the same NVRAM, just with external battery attached, so no Chineese counterfeit. My hypothesis is: With the battery losing voltage, some bits flip first. They cause the error message you see and values get set to proper values. But there are some bytes which must not flip because they determine e.g. the type of graphics, processor, speed, RAM timing etc. If one of these bits flips first, than one is lost because the machine does not reach the OpenBoot firmware because it tries to test non-existing hardware etc. etc.

Yes - exactly! Yes, that is different in the UltraBooks. There is very likely some deep hardware specific stuff in the NVRAM. In Tafpoles, SparcStations and similar (I have some of them) there is NEVER a sticker with the serial numer on the NVRAM, but in the UltraBooks there is. That is also anindication for me, that the NVRAM is paired to the hardware. Exactly - and therefore I fear, that all the UltraBooks will die, once the relevant bytes get lost. Mine operated for some years with the "Invalid NVRAM" message until I attached the battery to the NVRAM and herein completely erased it because it was completely without power for some time (old battery was down to 0.426V).

Yet we have a few datapoints showing that a dead NVRAM/RTC still boot UltraBooks just fine! As I said, I personally confirmed with my UltraBook IIe. Pretty sure the NVRAM is dead in my SPARCbook too, I can confirm that today. Thanks, Jonathan ------- Original Message ------- On Thursday, September 28th, 2023 at 05:08, erik--- via cctalk cctalk(a)classiccmp.org wrote: > > Hmmm, not sure on that one actually. So it does not boot up at all? > > Yes - exactly! > > > In the desktop Sun workstations and e.g. the Tadpole SparcBook, a lost NVRAM at least > > shows the firmware prompt on the screen (no HOSTID and no ethernet MAC). > > Yes, that is different in the UltraBooks. There is very likely some deep hardware specific stuff in the NVRAM. In Tafpoles, SparcStations and similar (I have some of them) there is NEVER a sticker with the serial numer on the NVRAM, but in the UltraBooks there is. That is also anindication for me, that the NVRAM is paired to the hardware. > > > situation is not as severe as with the UltraBooks where the screen remains black/dark and > > no interaction is possible! > > Exactly - and therefore I fear, that all the UltraBooks will die, once the relevant bytes get lost. Mine operated for some years with the "Invalid NVRAM" message until I attached the battery to the NVRAM and herein completely erased it because it was completely without power for some time (old battery was down to 0.426V).

Hi Ethan, thanks for suggesting MAME - did some research and somehow I do not think it emulates UltraSparc but only 32bit Sarc. But saw, that QEMU has a UltraSparc emulation and they... https://www.qemu.org/docs/master/system/target-sparc64.html ...explicitly claim that a NVRAM is emulated, although they are doing a M48T59 there is at least some chance that the memory address can be found in the QEMU sources. Will take a look in the next weeks ;-)

Yeah - reading the source code of QEMU I found the structure of the NVRAM - EVEN BETTER there was a WEB page with a good description of the various NVRAMs on Sun machines up to Ultra1. Yes, there "was". FORTUNATELY via archive.org, that page can be accessed - Tadaaaaaaaa- here it is: https://web.archive.org/web/20151107014449/http://www.squirrel.com/squirrel… HOT: As I suspected: The first byte of the hostID in some systems defines the machine type. PERFECT: There are also commands given to read/write the NVRAM from the firmware. Thanks Ethan, the hint to check the emulation was great!

Next step will be trying the same on my UltraBook (DS1643 instead of DS1553 on the UltraBook IIi). But need to Xray that one first before attaching a new battery.

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

Thanks Bill, that is cool! So failing display means it is black, but you hear it booting from the HDD? Do you know what type of NVRAM was used in the PowerLite? (Would be interesting if their NVRAM also has a "stop oscillator" bit which I attribute to the problems)