Japanese
  1. Reading our your old nvram (js)
    which nvram for which machine? (js) idprom structure (js, header)
    1. devinfo
    2. idprom (adrie)
    3. into a file (js)
  2. Refurbishing the old nvram (js)
    adding a new battery
  3. Writing the nvram
    1. using an eprom burner
    2. using a Sun3 (js)
    3. using a Sparc (js)
    4. using the prom monitor (adrie)
    5. Getting a new nvram from Sun
  4. Possible Problems
FOREWORDS:
==========

On ethernet addresses:  These should be unique, it's the main idea behind
them.  If you have also lost any reference to yours, try to find the number
for one that isn't used, like on those Novell PC Bugworks that will never
make it on the net.  Some Sys Architect informs me that there are ethernet
addresses databases you can get on alt.2600 or other places in order to see
what you should use if you ever had to "create a bogus one from scratch". 
Manufacturers are assigned the first part of the numbers by the "Ethernet
Big Authority Bureau", Sun seems to be 8:0:20:x:x:x .
Whatever you do, don't forget that Ethernet addresses are like fingerprints
on your packets.  UDP talks... too much.  
This is why Sun doesn't like you to touch it to avoid Net traffic accidents or
impersonalisation of machines on a local net.  So you've been warned.


On hostid:  You've all read the posts on licenses. Changing the serial
number of one machine in order to also run software licensed for an other
one...  This IS PIRACY.  It is the main reason why people used to buy 
Apple II's and now buy PC.  If it will boost SUN sales as well... :>  
This is why you'll stick with your hostid number.  This faq was made to help 
you when your NVRAM failed, not to help SUN selling more hardware.

  (Just call 1-800-555-pir8 and report yourself to the self-incrimination 
   service once you've changed your Hostid for the reason stated above.)  






 **************************************************************************
                                ORIGINAL FAQ
 **************************************************************************

Now that more and more elder Sparcstations pass the magic age of 5 years,
the problem of dying nvrams seems to get a FAQ.
I compiled what I could ask or get from previous postings,
so this heavily relies on information provided by two other persons:

    Adrie Koolen (adrie@ica.philips.nl)  (2 postings quoted)
    J"org Schilling (js@cs.tu-berlin.de) (almost everything else)

Thanks to them for sharing their knowledge.
I did mail a copy to mueller@cs.unc.edu (Carl Mueller) for inclusion in the
pseudo-FAQ if he whishes to.

/tatjana

  Contents:
  ---------

1 Reading out your old nvram:
  The Mostek MK48T02 2k nvram chip has been used in Sun3/80, sun4 and sun4c
  systems.  In sun4m systems they use the 8k version -but these are
  not dying yet.
  Sun is selling the MK48T02 for $70.
  In Germany they cost DM 45 / piece or DM 20 in larger quantities.
  From this I think that they might be between $10 and $25 in the US.

  idprom structure, from /usr/include/mon/idprom.h:
  01  format identifier 
    51, machine type -here a 4/60
      08 00 20 07 40 c7 ethernet address. (08:00:20:07:40:c7)
  and so on (see idprom.h)

These informations can be gathered in several ways:
1.1 devinfo: not ideal, as more handwork is needed to recontruct the nvram from these "human readable" informations.
1.2 From prom Monitor: .idprom -You need to write down the information.
1.3 From SunOS:
       The last 8 Bytes of the 2k are occupied by the clock. The size of 
       the idrom in a 3/50 is 32 Bytes (only the first 16 Bytes are used).
       To be compatible with the 3/50 idrom the last accessable 32 Bytes 
       in the 48T02 are used. Therefore the offset of the id-data is:
       2k - 32 bytes - 8 bytes.
       Therefore, for all machines with a 2k nvram:
                     open /dev/kmem, lseek to ffff8000, read 2k 
       All sun4m machines (8k nvram):
                     open /dev/kmem, lseek to feffe000, read 8k 
       Poor dd can't lseek -it would save us writing these
       mini-programs. (Sorry, nothing "ready to go", -Joerg uses his own dd)
       never mind that this offset is negative -it does work :)
       For SunOS4 these adresses can be found in header files.
       This information vanished with Solaris 2.x, but it's valid anyway.
2 Refurbishing the old nvram:
  The contents of the (nv)ram are backed up by a 3V lithium battery.
  It's located together with a quartz on top of the ram in a kind of backpack.
  The battery is on the side that's opposed to the dot marking pin 1,
  next to pin 12:

                         _oscillator
                        /
                       / _battery
                      / /
                   -------
                   | O O | <-- cut here 
                   -------
                  /
             Pin 1

   At the point marked above, some kind of nose is reaching down from the
   backpack over the resin.
   Carefully cut through the polyester resin filling the dimple.
   This works best with some kind of mini drill with a small milling head.
   buried in the resin you'll find two small diagonal metal connectors :).
   Be careful not to short-circuit them, or you'll loose the contents of your
   nvram (if it was still able to keep them). -That's why you should save them
   *before* :)
   The connector closest to pin 12 is ground, the other (opposing) one +3V.
   You can now solder some wire to them and connect them to a new 3V lithium
   battery.
   If you find that the ram has been erased during this procedure, try to
   rewrite it using one of the following approaches.
3 If you have to write a virgin or erased nvram:
3.1 an eprom burner able to handle the 48t02
3.2 any Sun 3 system which has a socket for the eeprom.(i.e. not a 3/60)
      - Remove the eeprom 
      - Insert the nvram in its place
      - Set the 3-something to diag mode (It usually won't boot otherwise,
        at least not with a virgin nvram, as with these the checksum is
        usually ok. this leads the poor thing into taking the dummy crap for
        valid nvram data) 
      - Boot 
      - use dd to write the first 2040 bytes from your save file to /dev/eeprom.

      With a Sun 3/80 you could just replace the old nvram with the new one
      as /dev/eeprom is writable there as well.
      I didn't test yet if it's coming up with a valid but senseless nvram,
      though. Unlike the other Sun 3 machines, the 3/80 doesn't have a switch
      for setting the diag mode but sets this in the nvram instead :(.

      J"org uses a 3/50, equipped with a textool socket for this
      procedure.
3.3 Your Sparc:
      - Read the nvram out as described above.
      - Make sure you can reboot it without the net.
        (rename /etc/defaultdomain, turn automounter off, etc)
      - Switch your Sun off
      - Exchange the old idprom for the new one.
      - Don't connect this machine to your network, with the empty nvram it
        will come up with the broadcast address ff.ff.ff.ff as ethernet address.
      - Boot from local disk. It will complain about the defective idprom
        but boot anyway.
      - Patch resettodr in your kernel to make the nvram page writable:
         (Tested with SunOS 4.1.3 - different release might result in a
          different location)
          things you have to type are preceeded with a pseudo-prompt "> ",
          to distinguish them from the output you'll get, even though
          in kadb there will be no prompt at all.

            root@hostname> adb -w -k /vmunix /dev/mem
            > resettodr+3ac /i        
              resettodr+3ac:    call  _mmu_setpte  # If you get anything else,
                                                   # don't proceed!!! DANGER !!!
            > /W1000000                            # Note the /, you don't want
                                                   # to patch /vmunix on disk :)
            > /i                                   # look what we've done 
              resettodr+3ac:    nop                # should be a nop now.
            > $q                                   # leave adb
            root@hostname> date 9404212300         # set the date       

          Now, after setting the date, the nvram is writable at the address
          mentioned before.
          open /dev/kmem r/w,
          seek to the address,
          write 2040 bytes from the save-file (don't overwrite the clock)
          close /dev/kmem
          reboot (you don't want to keep this page writable)
 
  Everything should be as before now :)

  Joerg gathered these informations by disassembling resettodr.
  If your version of /vmunix is different (no call _mmu_setpte at resettodr+3ac)
  you have to walk through this routine and find the location of the last 
  call _mmu_setpte (called twice). The second and last one is the one to be
  patched.
            > resettodr /i        
            > [return]                           # step through
               .                                 # with return 
               .                                 # until you hit
            > [return]
              resettodr+?:    call  _mmu_setpte  # Nr 1
            > [return]
               .
               .
            > [return]
              resettodr+?:    call  _mmu_setpte # Nr 2 -write down the location
                                                # and continue as descibed above
3.4 Restoring identity from prom monitor:
      If your battery is already gone and you don't have a backup of the
      idprom contents, you'll either have to pay Sun, or, if you do know the
      most important values (ethernet address, and serial number or hostid),
      you can rebuild the contents of your idprom.
      The ethernet address you might find in /etc/ethers or the yp map ethers
      if you ever cared to enter the ethernet addresses there.
      The hostid is the hex notation of the serial number, so you only need
      one of them. You might have home hostids in license files.
      Bills might also give you the information needed.

      From: adrie@ica.philips.nl (Adrie Koolen)
      Subject: Re: SS1+: Incorrect configuration checksum
      Date: Tue, 22 Mar 1994 13:53:41 GMT

      The idprom is a 32 bytes part of the non-volatile ram. The last 16 bytes
      of it have been reserved (i.e.: 0). The .idprom forth command and the
      "/usr/etc/devinfo -vp | grep idprom" SunOS 4.x command give you those
      32 bytes. A very crude way of putting data in the idprom is:

        enter the forth (booot prom) monitor (e.g. via L1-a, possibly
        followed by "n ".

            ok f7002000 ffd04700 pgmap!
            ok 01 ffd047d8 c!
            ok 51 ffd047d9 c!
            ...
            ok 00 ffd047f6 c!
            ok 00 ffd047f7 c!
            ok reset

      The 32 bytes are the 32 successive bytes reported by the .idprom command
      or devinfo command. You might use the l! forth command to store 32 bits.
      This saves you some typing. Note that the `51' is only valid for
      SparcStation 1 computers; other systems have other numbers...

      !!! Please note that this procedure might make your SparcStation !!!
      !!! unusable if not correctly executed. Sun definitely does NOT  !!!
      !!! support this. Be very carefull when restoring the contents   !!!
      !!! of your IDPROM.                                              !!!


      From: adrie@ica.philips.nl (Adrie Koolen)
      Subject: Re: dead NVRAM
      Message-ID: <1994Feb10.092712.1253@ica.philips.nl>
      Organization: Philips Consumer Electronics, Eindhoven, The Netherlands
      Date: Thu, 10 Feb 1994 09:27:12 GMT

      [...quoted posting omitted...]]
      An answer from someone at Sun. I can imagine that they don't want people
      poking around in the hostid and ethernet addresses, but you can of course
      set them yourself. As Glenn already told, you first have to get a new
      Mostek MK48T02 chip and exchange it with the broken one in your
      SparcStation.
      Then turn on the SS and let it discover that the NVRAM is empty. It fills
      it with factory default values but leaves the idprom contents untouched.
      The idprom is stored at offset 0x7D8 in the 2kB static RAM. To prevent
      writing in the NVRAM, the NVRAM page is read-only.

      **** Dangerous Action ****
      To change the hostid, power on the SS and get into the monitor (ok prompt).
      Then make the NVRAM page writeable:
    
            ok F7002000 FFD047E5 pgmap!

      Now set the hostid to 51123456:

            ok 51 FFD047D9 c!
            ok 12 FFD047E4 c!
            ok 34 FFD047E5 c!
            ok 56 FFD047E6 c!

      You should also set the format, ethernet and checksum bytes. Use the

            ok .idprom

      command to view the current contents and order of the bytes. The checksum
      is an exclusive-or of the first 15 bytes of the idprom.
      **** End Dangerous Action ****

      I urge you to use extreme precaution changing the contents of the idprom!
      Doing something wrong can make your SparcStation unusable. Always first
      use the .idprom command and write down the current contents of the idprom
      before changing anything.

      We've got quite a few SparcStations here and I've already seen some of
      our older SparcStation 1's failing to boot because of an empty NVRAM.
      Sun made a design mistake using the Mostek MK48T02 (my opinion) as some
      of them don't last for even 5 years!

      Adrie Koolen (adrie@ica.philips.nl)
      Philips Consumer Electronics, Eindhoven, the Netherlands
3.5 Getting a new nvram from Sun:
      If everything fails, i.e. the nvram is already dead and you don't
      know ethernet address and serial number or hostid, you can only send
      the nvram in to Sun. The barcode on top serves to identify the idprom
      and they'll send you a new one back in about 2 Months.
      Sun Germany charges DM 200 for this.
      From this I'd guess that in the US this might be < $100
4 One last possible problem:
  The clock needs a kick in the *** to start running.
  (In a virgin nvram it's in sleeping mode to save on battery life)
  The clock driver should be able to handle this.
  From /usr/include/machine/clock.h (/usr/include/sys/clock.h in solaris2)
  you can see how this is done.

  It's somewhat non-trivial though, so if your clock driver does not handle
  it you can ask Joerg about the procedure (mail to js@cs.tu-berlin.de).
-- 
Tatjana Heuser      | pierrot@cs.tu-berlin.de
Ettaler Str.2       |
D-10777 Berlin      | +49 30 / 214 27 58       






  *************************************************************************
                               IDPROM TEMPLATE
  *************************************************************************


The idprom.h include file is a copyrighted document you can slurp yourself
from any Sun Os 4.1.x server you have access to... like yours ?!

Here is in short how the idprom is like on a Sun Sparcstation IPC with BOGUS
hostid and date.  The ethernet address is the one used in the FAQ.
Use your parameters instead!


HOSTID:  It's the hex representation of the Serial Number with a leading CPU
ID byte.  Here 51 and 12 34 56, so HOSTID = 51123456


Bogus but possible machine profile :
====================================
Sparc IPC, sun4c 4/40
Serial #1193046
Ethernet: 8:0:20:7:40:c7
HOSTID: 51123456
date: 0 1 2 3
Checksum: 87

(All values in table are in hex !!!)
  

BYTE	Address		Value		Description
=============================================================================
 1	ffd047d8	01		Always 01... Means prom number.	
 2	ffd047d9	51		CPU ID, 51 for sun4c, SPARC 1+
 3	ffd047da	08		First number of ethernet address
 4	ffd047db	00		Second	""   ""    ""       ""
 5      ffd047dc	20		Third   ""   ""    ""       ""
 6      ffd047dd	07		4th	""   ""    ""       ""
 7      ffd057de	40		5th	""   ""    ""       ""
 8	ffd057df	c7		6th number of ethernet address
 9	ffd057e0	00		1rst number for DATE
10	ffd057e1	01		2nd number for DATE
11	ffd057e2	02		3rd number for DATE
12	ffd057e3	03		4th number for DATE
13	ffd057e4	12		Serial Number (part 1 of 3)
14	ffd057e5	34		Serial Number (part 2 of 3)
15	ffd057e6	56		Serial Number.gif (part 3 of 3 :)
16	ffd057e7	87		Checksum byte.

17	ffd057e8	00		UNUSED
..      ........        ..              ......
32	ddf057f7	00		UNUSED


Well that's about it.  The XOR checksum is not byte1 xor byte2 xor ...byte15
I'm an assembler kid, not a C include file eater, so who ever got a chance
in that direction could please E-mail me the trick.  Compiled language
assemble weirdly :>  I'll include it in the next edition.
Thanks for bearing with my silly comments...  Hope you'll recover from your
bad nvram and don't do anything silly.


Have fun !

--
                                     Denis Solaro -- drzob@vectrex.login.qc.ca