[wroteafaq]

So you know how you're looking for something, and you *know* you had it, because you can see it in your mind, and after a while of not being able to find it you wonder whether your memory is just screwing with you and maybe it never existed at all or you're just confusing it with something else?

Well, this is that. I found my notes on setting the Indy address using "fill", but I'm *sure* I was doing it with the Indigo, because I didn't have to (recently) mess with the Indy's address - I think - but I sure as hell can't find anything that tells me which addresses to fill in the Indigo.

Anyway, to cut to the chase, it appears you can set the MAC address on an R3K Indigo simply by using the "eaddr" command:

eaddr 08:00:69:xx:yy:zz

where xx:yy:zz are the three octets of your choice. eaddr without the argument just tells you what it's set to.

[megaimg]

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

I need your help, sound like you have the EEPROM info for both Idigo 3k and 4k....I need to get the back plane back to 3K, can you provide the eeprom file and a good place for the procedure. Thanks!