If you have as many Sun boxes as I have, you end up reprogramming the timekeeper what seems like every month. It’s not really that often — just long enough that every time, I have to look up the machine type, make up a new address, write it down on a piece of paper, and then sit down at the console and type it all in.

So I had the idea of making a script generator to do the lookups for me and write out exactly what I need to type — or, optionally, just copy and paste at the ok prompt.

The canonical byte-by-byte procedure lives in Resetting IDPROM on Sun Workstations, and the chip-side of the same problem (replacing or battery-modding the dead timekeeper) is over in M48T02 Timekeeper External Battery Mod. This page is the part where you pick your model and it hands you the exact lines for the OpenBoot monitor, with a fresh Sun-OUI MAC address baked in.

Which chips this covers

Sun used several timekeeper parts across the SPARCstation line, but they all share the same 16-byte IDPROM layout, so the same mkp sequence works on every one of them. The generator below is chip-agnostic — only the model of the machine matters, not which timekeeper is socketed in it.

ChipTypical Sun systems
M48T02SPARCstation 1, 1+, IPC, IPX, SLC, ELC, 2
M48T08SPARCstation 10, 20, 600MP series
M48T18 / M48T35SPARCstation Classic, LX, 4, 5, Voyager
M48T58 / M48T59Ultra 1, Ultra 2, and later sun4u systems

If you’ve replaced a dead chip with a fresh one, or revived the original with a coin-cell mod, the IDPROM is blank and the firmware will boot with hostid 0 until the bytes below are programmed in.

What the generator is doing

The IDPROM holds 16 bytes. Byte 0 is always 01 (the format version). Byte 1 is the machine type that tells SunOS which SPARCstation it is talking to. Bytes 2–4 are Sun’s OUI (08:00:20), and bytes 5–7 are the unique tail of your Ethernet address. Bytes 8–b are a manufacturing date and are fine left at zero. Bytes c–e repeat the MAC tail; combined with the machine type byte they form the 4-byte hostid that software licensing keys to. Byte f is an XOR checksum across all the others.

OpenBoot re-runs that XOR every time the machine powers on and compares the result to byte f. If they don’t match you get the “IDPROM contents are invalid” warning at boot, the hostid reports as 0, and the Ethernet address falls back to all-zeros or all-ff. That is why the trailing Forth line in the script is mandatory — it is not storing a pre-computed value, it is computing the XOR live with 0 f 0 do i idprom@ xor loop and writing the result so the next boot’s verification passes.

One side effect of the byte layout: because bytes c–e mirror bytes 5–7, the MAC tail XORs with itself and cancels out, so the checksum reduces to 0x29 ^ machinetype — a constant per model. Reroll the MAC all you like and the checksum byte will not move until you change the model.

The generator picks a fresh random tail every time you load the page or click Pick a new MAC, so each machine you revive gets a unique address. The MAC is locally administered in the practical sense — it is real Sun OUI space, but as long as no other SPARCstation on your network shares the last three bytes you will not have a collision.

Using the output

You have two reasonable options:

Type it at the console. Bring the machine to the ok prompt with Stop-A, then type each line. Hex values in OpenBoot are entered without a 0x prefix. The final line,

0 f 0 do i idprom@ xor loop f mkp

walks bytes 0 through e, XORs them together, and stores the result at byte f. Then reset reboots cleanly.

Pipe it through tip(1) or a serial console. Save the script with the Download script button and paste it into a tip hardwire or cu session. Most terminal programs will throttle the paste enough that the OBP forth interpreter keeps up. If you see dropped characters, slow the paste rate or insert short delays between lines.

A note on the “80” group

Machine type 80 covers a whole family of later sun4m and sun4u systems (Classic, LX, 4, 5, Voyager, Ultra 1, etc.) that share the same IDPROM layout but ship with OpenBoot 3.x. The procedure here works on those systems, but on a fresh NVRAM you may also want to set mfg-mode? false and confirm diag-switch? is false before running the pokes. If the machine ignores Stop-A on the first try, power-cycle it with the keyboard unplugged for a moment and try again — a stuck key on a dying keyboard can mask the break.