August 22, 2025

Sun 3 bootrom souce - the Sun 3/80 - nvram

When we watch the diagnostics during my first "in a long time" power up, we see:
I should say so. It isn't low, it is dead. At least I'm sure that after over 30 years it is dead.
Then after diagnostics finish we see: 
ID PROM invalid.
ERROR: missing or invalid ID prom

NVRAM, EEPROM, or IDPROM?

These 3 terms get tossed around, even by the bootrom itself. So what is the story?

The 3/80 has NVRAM in the form of a M48T02, made by ST electronics. This is a 2Kx8 static ram with a piggyback battery. It also includes a clock/timer with some registers that hide the last few bytes of the ram.

This chip is the whole story for the 3/80. Older boards, like the 3/160 had an EEPROM along with an IDPROM. No battery on the old boards, which is nice. They still work after all this time without hassle or fuss. On these old boards the EEPROM was a 2Kx8 device and the clock/timer was yet a different chip. The IDPROM was a small bipolar memory that was programmed at the factory. It contained, among other things, the ethernet address.

Stick with me for how this plays out with the 3/80. First look at these addresses from the lovely "^A" command that the 3/80 prom provides: 

Device:         Virtual Address: Physical Address:
EEPROM          0xFEF04000:      0x64000000:
TOD             0xFEF06000:      0x640007F8:
IDPROM          0xFEF047D8:      0x640007D8:
Look at the physical addresses. These are all in the same chip!

The TOD clock/timer registers at 0x7f8 cover the last 8 bytes of the ram in the M48T02, as we already have mentioned. But look! The IDPROM is just the last 32 bytes of that 2K ram! How much would you bet that the bipolar ROM used on a 3/160 was 32 bytes in size? This leaves the first 2k - 40 bytes of the static ram (battery backed) for what is erroneously called EEPROM.

I suppose we can forgive the Sun rom in this case. Although hardware wise, it is not really EEPROM, Sun sort of usurped the term EEPROM for what holds system configuration. So it is more of a functional term in that context.

For completeness at the risk of confusion, look at this address scheme as used by the Sun 3/160. 

EEPROM -- 0x6400_0000  (0xfef0_4000 virtual)
TOD    -- 0x????_????  (0xfef0_6000 virtual)
On my board, the EEPROM is a SEEQ DQ2816A device. It is rated for 10,000 write cycles. the 5516 part number you see on the schematic is a pin identical device that allows up to 100,000 write cycles. It has no timer tucked away in the last 8 locations.

The clock/timer on the 3/160 is the Intersil 7170 chip. It is at an entirely different physical address and it seems unlikely that it has identical registers to the timer in the M48T02. However it is mapped to the same virtual address.

The IDPROM in the 3/160 is in a wildly different location.

How to get my 3/80 to boot

My 3/80 is not going to do anything that I would like it to do until I do something about the dead battery in the M48T02. I see 3 options: I actually think that rigging up a coin battery is the best solution. If I buy another M48T02, the battery in it will just go dead eventually. A coin battery in a holder can be easily replaced.

A software solution

I have a working serial connection. The M48T02 still functions as ram, it just doesn't hold data when powered off. I could write a program that runs on my linux machine and communicates with the bootrom and configures the "EEPROM" each and every time I power the machine up. This would be an interesting programming task rather than somewhat delicate cutting and soldering -- and I might try it.

Use the bootrom

The "Q" command in the bootrom accesses the EEPROM.

If you just type "q", it starts displaying bytes at address 0.
If you type "q7d0" it will start displaying at address 0x7d0.
You can do one of three things:

It is quite happy to let you look at values in the IDPROM area beginning at 0x7d8, but it won't let you modify them. I suppose this was intended so that ignorant users did not corrupt the IDPROM information.

You can look at the TOD registers in the 0x7f8 to 0x7ff range also. You can write to them also. They don't behave as ram, being device registers after all.

What goes into the IDPROM area?

7d8  --  01  version number, always this
7d9  --  42  first byte of hostid
7da  --  xx  1st byte of ether
7db  --  xx  2nd byte of ether
7dc  --  xx  3rd byte of ether
7dd  --  xx  4th byte of ether
7de  --  xx  5th byte of ether
7df  --  xx  6th byte of ether
7e0  --  00  date of manufacture
7e1  --  00  date of manufacture
7e2  --  00  date of manufacture
7e3  --  00  date of manufacture
7e4  --  yy  serial
7e5  --  yy  serial
7e6  --  yy  serial
7e7  --  ss  checksum
There you go, 16 bytes in all.
The checksum is just the XOR of the 15 preceding bytes.

A subterfuge

The recipe says to set EEPROM 70b to 6: 
q70b
6
We have to work around the bootrom protecting the IDPROM area.
I type the following 
^t fef04000
Virtual Addr 0xFEF04000 is mapped to Physical Addr 0x64000000.
TIA Entry = 0xFFA500, TIB Entry = 0xFFB80A.
PTE = 0x64000049
Then we do: 
m a fedfa000
ffa500
.
m b fedfa000
ffb80a
.
p fedfa000
64000049
.
o fedfa7d8
Now you type in the 16 bytes for the idprom. You can use "q 7d8" to check.
I use "k2" to reboot.

Note! I only set the 16 IDPROM bytes in the NVRAM to get this to work! There is plenty of other stuff in the NVRAM, but we don't need to worry about it to get the machine booting.

Another note! After doing this and using it for an evening of tests, I powered the unit off for nearly 24 hours. When I turned it back on, it remembered the configuration! I hardly expected that. It is certainly a time saver.

Now it tries to boot

We continue this in another page.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org