[wroteafaq]

Hi, folks.  I can't believe I'm new here; I've been slinging SGIs for a really long time, but have been away for a while and am now getting back in.

Quick question (I think):  I have a rather large pile of mixed Indigo parts that I want to turn into as many working systems as possible.  I have at least one working 3K system and one working 4K system, and probably more.  Since in many cases I don't know which CPU was in which box, I don't know which backplane has the correct E^2 settings for which CPU.  I have the necessary PROM burner here, but if there's an easier way I shouldn't have to press it into service.

So please tell me if I have this right:

1. Inserting a 3K CPU into a backplane with a blank/erased E^2 will cause the CPU to initialize the E^2.
2. Inserting a 4K CPU into a backplane that previously held a 3K will cause the CPU to "upgrade" the E^2.

But I don't know what happens if you plug a 3K into a backplane that previously ran a 4K.

Nor do I know what happens if you plug a 4K into a backplane with a blank/erased E^2.

I can certainly confirm/determine all this experimentally, but I'm a little oversubscribed at the moment (including having many trees to cut up as a result of a serious windstorm a couple of weeks ago), so it would be of tremendous help if anyone could sort me out.

Thanks much.

Jonathan

[indigofan]

Either way with a switch, you will more than likely need to reset the EPROM, I had to do it when swapping chips from a R4K to a R3K and then back again.. if you search here on the forum you will find the command to do it.

[jan-jaap]

Whatever you do, make sure to not use an R4K CPU board in a system with an R3K-rated power supply. It may release magic smoke.

I speak from experience

[wroteafaq]

Either way with a switch, you will more than likely need to reset the EPROM, I had to do it when swapping chips from a R4K to a R3K and then back again.. if you search here on the forum you will find the command to do it.

Turns out that both the 3K and 4K behave the same way:  When you plug in a blank E^2 the CPU initializes it - everything but the MAC address, which is a deal-stopper, as it won't boot without a valid one (well, it boots, then panics).  But it's nice that it gets that far.  I found elsewhere discussions of how the 3K ROM monitor - but not the 4K - can be used to change the address, and that's fine, but a fussy difference.  So I'm just munging them in the Data I/O.

---

Whatever you do, make sure to not use an R4K CPU board in a system with an R3K-rated power supply. It may release magic smoke.

I speak from experience

Yeah, I picked up on the 4K using a higher power supply.  But letting out the magic smoke is not a very graceful way to respond to an overload condition; one expects in a quality system that the switcher would just shut down.

[dexter1]

Back in the days i have made a write up and some dumps of the R3K and R4K indigo backplane EEPROM.
I have posted it on Nekochan, but i fortunately made a copy. If you need additional info, like the EEPROM dumps or the PROM program, i can attach those here, or post it on my page, if i remembered how to do that...

NOTE: If someone has a solution for the replacement of 'ff' in code formatting please do tell, because my OCD is triggered when i see the misalignment in my EEPROM dumps in the code block.


Hi all,

This is supposed to be a nice readup for all of you Indigo lovers, panting away
in this summer heat, wondering why your R3K motherboard won't work in an R4K
chassis. Or vice versa... Or you just want to change your MAC address ;>
Or you don't have a bootdisk handy and want to get rid of that PROM password :(

The short answer to this is that the R3K and R4K Indigo uses the same
backplane chassis, but the 93CS56 EEPROM on it, used as the nvram in these
systems, has a different memory layout. There actually is a pretty good posting on usenet
two years ago, which discusses this:
http://groups.google.nl/groups?hl=nl&lr=...26rnum%3D9

There is also a tricky catch with this flash eeprom. It has 128 words of memory it can
store, but also has a byte register where it keeps the address of the byte from
which there is no programming possible anymore. So if this byte is at 0x7a (it
is in the case of an eeprom in an R3K system case #CMNB003) and looking at a
dump of the EEPROM:

Code:

00000  63 56 31 39 32 2e 30 2e 32 2e 31 00 00 00 00 00 cV192.0.2.1.....
00010  00 00 39 36 30 30 00 31 32 30 30 00 67 00 00 00 ..9600.1200.g...
00020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ................
00030  ff 41 30 00 64 6b 73 63 28 30 2c 31 2c 38 29 73 .A0.dksc(0,1,8)s
00040  61 73 68 00 00 00 00 00 00 00 00 00 00 00 00 00 ash.............
00050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00070  00 00 00 00 00 00 00 31 32 38 08 00 69 06 91 77 .......128..i..w
00080  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00090  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000a0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000b0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000c0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000d0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000e0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
000f0  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................

You quickly see that it prevents you from overwriting the MAC address located at
0x7a-0x7f and anything beyond that.

Which is a pity because a dump of an eeprom in an R4K system case #CMNB003B :

Code:

[php]00000  be 06 67 00 00 00 00 00 00 00 10 00 18 00 1c 00 ..g.............
00010  1e 00 1f 00 1f 80 1f c0 1f e0 1f 00 1b 00 11 80 ................
00020  01 80 00 c0 00 c0 00 00 30 00 28 00 24 00 22 00 ........0.(.$.".
00030  21 00 20 80 00 00 00 00 00 00 10 00 18 00 1c 00 !. .............
00040  1e 00 1f 00 1f 80 00 00 00 00 00 00 10 00 18 00 ................
00050  1c 00 1e 00 1f 00 1f 80 1f c0 1f e0 1f 00 1b 00 ................
00060  11 80 00 00 00 00 00 00 10 00 18 00 1c 00 00 00 ................
00070  00 00 00 00 39 36 30 30 00 30 ff ff ff ff ff ff ....9600.0......
00080  50 53 54 38 50 44 54 00 00 00 00 00 00 00 10 00 PST8PDT.........
00090  18 00 1c 00 1e 00 1f 00 1f 80 1f c0 1f e0 1f 00 ................
000a0  1b 00 11 80 01 80 00 c0 00 c0 00 00 30 00 28 00 ............0.(.
000b0  24 00 22 00 21 00 20 80 59 00 00 83 ea 50 4c 31 $.".!. .Y....PL1
000c0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000d0  00 00 00 bf c4 96 94 bf c4 96 b8 bf 00 00 00 00 ................
000e0  bf c4 96 94 bf c4 96 b8 bf c4 96 dc bf 00 30 00 ..............0.
000f0  00 00 79 00 00 18 ff ff ff ff 08 00 69 06 a4 0d ..y.........i...[/php]

the mac address is located all the way back at 0xfa-0xff.
Hence, when an R4K HP2 mainboard is presented with an R3K eeprom, which is
locked in the above manner, networking is disabled because it sees
0xffffffffffff as its MAC address.


To add my two cents to this discussion, it is actually very easy to change the
EEPROM contents without buying an expensive EEPROM tool. You just need eight
wires, a male db25 connector, an 8 pin DIL socket where the 93CS56 fits in, and
a free power connector in your (linux) PC which can deliver 5 V

The connections are as follows (the "u" in the picture is a halfcircle cutout on
your EEPROM):

Code:

cs  1=u=8  vcc
sk  2   7  pre
di  3   6  pe
do  4===5  gnd

Parallel port pins:
cs connects to pin 2
sk connects to pin 3
di connects to pin 4
pe connects to pin 5
pre connects to pin 6
do connects to pin 12
vcc is +5v
gnd is pin 18-15 or shielding

I'll try to present a nice photo of my EEPROM burner in a few days.

Furthermore you need my program called 93cs56.c available here:
(stale link removed)

Compile this program on a PC linux system: cc -o 93cs56 93cs56.c
and you're ready to go (as root though):

Usage:
93cs56 r pos          read from pos
93cs56 w pos hb lb    write to pos
93cs56 l filename    load all from filename
93cs56 s filename    save all to filename
93cs56 p              read from Protection Register
93cs56 c              clear Protection Register
93cs56 x b            write to Protection Register

First save the original contents to a file (do it twice to verify that the data
is stored correctly):
93cs56 s dump
Also note the protection register:
93cs56 p

Then clear the protection register:
93cs56 c
And start loading that eeprom image:
93cs56 l R4000nvram


I think you can even meddle with a different MAC address as the eeprom contents
doesn't appear to be crc checksummed. My R3K eeprom image was identical to the
above dump except for the MAC address (obviously):
00070  00 00 00 00 00 00 00 31 32 38 08 00 69 06 2D 22 .......128..i.-"
and one byte over here (the A5):
00030  FF A5 30 00 64 6B 73 63 28 30 2C 31 2C 38 29 73 ..0.dksc(0,1,8)s

If that really is checksummed, it can't be hard can it?
I have no idea about the R4K, will test this someday...

Enjoy playing with that. I have more to say on the 93cs56, because it also sits
on Indy/indigo modules, holding the multiplier for the R4k CPU's. I'm still
working on that one, but sofar no indy has died yet

I welcome any comments/suggestions on this...

[wroteafaq]

(A side note: It triggers *my* OCD when people use the terms "FLASH", "NVRAM", and "EEPROM" interchangeably or in combination. They are three completely different things (other than FLASH being a special subset of EEPROM - all FLASH are EEPROM, but not all EEPROM are FLASH) and should not be confused. The only characteristic they have in common is nonvolatility, so if we're going to be sloppy we might as well just call the memory in question "core", because that's nonvolatile too. If anyone needs clarification on this point I'd be happy to offer it.)

All useful information, particularly for those lacking device programmers. But I think you (and the posters in that old comp.sys.sgi.admin thread) have gotten rather far out into the weeds. As I would seem to have found, it's a pretty simple problem to solve: Stuff a blank E^2 into the socket. Power the system up, which initializes the E^2. Use the monitor (3K) or burner (3K, 4K) to enter the MAC address of your choice. Bob's your uncle.

No fussing about with protection registers or checksums needed, afaIk.

[robespierre]

(A side note: It triggers *my* OCD when people use the terms "FLASH", "NVRAM", and "EEPROM" interchangeably or in combination. They are three completely different things (other than FLASH being a special subset of EEPROM - all FLASH are EEPROM, but not all EEPROM are FLASH) and should not be confused. The only characteristic they have in common is nonvolatility, so if we're going to be sloppy we might as well just call the memory in question "core", because that's nonvolatile too. If anyone needs clarification on this point I'd be happy to offer it.)

I've observed a similar type of confusion. Computer vendors may be to blame: they've mixed up the terms a lot, possibly because of changes in how technology is implemented and a desire to keep the same words in use for software and documentation. For example, the word "PROM" was used by SGI for its firmware environment, despite it never residing in an actual (fusible) PROM.

Also a nitpick: Simtek/Cypress/Infineon sells a device with a NVRAM interface and Flash internal storage (it uses a capacitor to run the Flash write machine after detecting power-fail). They call it "nvSRAM". So it can be correct to use these terms in combination. In the end, I'm not sure that users without a subscription to EDN can be expected to tell them apart.

[wroteafaq]

I've observed a similar type of confusion. Computer vendors may be to blame: they've mixed up the terms a lot, possibly because of changes in how technology is implemented and a desire to keep the same words in use for software and documentation. For example, the word "PROM" was used by SGI for its firmware environment, despite it never residing in an actual (fusible) PROM.

Also a nitpick: Simtek/Cypress/Infineon sells a device with a NVRAM interface and Flash internal storage (it uses a capacitor to run the Flash write machine after detecting power-fail). They call it "nvSRAM". So it can be correct to use these terms in combination. In the end, I'm not sure that users without a subscription to EDN can be expected to tell them apart.

Heh.   Pretty much right - though I can even nitpick with *you* over the definitions.  Yes, a PROM is traditionally a bipolar, fusible-link device, but one can make a strong argument for simply calling an OTP UV EPROM a "PROM", because it's effectively one-time programmable and no longer (practically) erasable...

</nitpick>

[dexter1]

I would like to add another $0.02

But I think you (and the posters in that old comp.sys.sgi.admin thread) have gotten rather far out into the weeds.  As I would seem to have found, it's a pretty simple problem to solve:  Stuff a blank E^2 into the socket.  Power the system up, which initializes the E^2.  Use the monitor (3K) or burner (3K, 4K) to enter the MAC address of your choice.

If it is a blank 93CS56/EEPROM/FLASH/NVRAM/E^2/DIL then i would expect the Indigo HP1(R3K) and HP2(R4K) board to behave differently when it comes to initializing the chip as opposed to backplanes already having a chip initialized. Have you checked all the different combinations? If i missed this in your previous post, apologies, i blame my geriatric eyes.

I found elsewhere discussions of how the 3K ROM monitor - but not the 4K - can be used to change the address, and that's fine, but a fussy difference.

I do not seem to have the procedure written down for reprogramming the empty EEPROM with the R3K monitor. Can you post that procedure, or point us towards that info? For EEPROM's already initialized, Dave Olson (that quoted '93 post from the thread i linked) mentioned that networking of a HP1 in an R4K initialized backplane doesn't work which i reproduced in my HOWTO, since after all, Dave Olson is Dave Olson.

No fussing about with protection registers or checksums needed, afaIk.

Regarding the checksum, that doesn't seem to be necessary when programming it, it will still work. However the EEPROM protection register needs to be reset when preparing an already initialized R4K backplane EEPROM for accepting an HP1. The protection register is not permanently locked however, they do not seem to bother perma-locking it in the Indigo systems.

One of my fellow countryman SGI collector had this exact same issue and i pointed him to my Nekochan post. Alas i don't know if he was successful in reviving the network on that system...

Ideally, it would be best to keep the pair of board and backplane/case together, but after 30 years...

[wroteafaq]

I would like to add another $0.02

If it is a blank 93CS56/EEPROM/FLASH/NVRAM/E^2/DIL then i would expect the Indigo HP1(R3K) and HP2(R4K) board to behave differently when it comes to initializing the chip as opposed to backplanes already having a chip initialized. Have you checked all the different combinations? If i missed this in your previous post, apologies, i blame my geriatric eyes.

(I'm not sure the quoting is working properly here, so forgive me if it's screwed up.)

Honestly, once I discovered that both of the CPUs would just initialize a blank E^2, then I could tack in the MAC address with the Data I/O, I stopped playing with it, because that's the shortest route for me and I have a pile of machines to grind through.  If I were writing a FAQ I might go through all the combinations, but not at the moment.

I found elsewhere discussions of how the 3K ROM monitor - but not the 4K - can be used to change the address, and that's fine, but a fussy difference.

I do not seem to have the procedure written down for reprogramming the empty EEPROM with the R3K monitor. Can you post that procedure, or point us towards that info? For EEPROM's already initialized, Dave Olson (that quoted '93 post from the thread i linked) mentioned that networking of a HP1 in an R4K initialized backplane doesn't work which i reproduced in my HOWTO, since after all, Dave Olson is Dave Olson.

Again, you'll have to forgive me.  I'm working on these things as I'm setting up a new workspace (in what was a messy storage area, so I'm concurrently cleaning up) and in addition to the Indigos I'm hacking UniSite internals.  So I *know* that the procedure is on a piece of paper (printed out from the site where I found the instructions), but at the moment I just don't know where the hell it is.  As things get more organized I know it'll turn up and I'll be happy to post the link.

No fussing about with protection registers or checksums needed, afaIk.

Regarding the checksum, that doesn't seem to be necessary when programming it, it will still work. However the EEPROM protection register needs to be reset when preparing an already initialized R4K backplane EEPROM for accepting an HP1. The protection register is not permanently locked however, they do not seem to bother perma-locking it in the Indigo systems.

Again, it's just not a detail that I need to care about at the moment.  As long as I can pull the part from the backplane, erase it in the Data I/O, reinstall it in the backplane and initialize it with the CPU, install the address with the UniSite, and finally plug it into the backplane again, I'm happy.  It sounds like a lot of schlepping of an 8-pin DIP, but in reality the entire operation takes a couple of minutes.  I can afford that.