SGI: Hardware

How much faster theoretcaly can be RM7900@900 than R7000@600?

Someone at SGI did design a new low-end which ran IRIX using a newer Broadcom dual-core MIPS CPU, but
I don't know what the clock was. I infer from what I was told that the unit was designed around PCIe, and had
an NVIDIA gfx card. It never went anywhere though, management killed it. :\

Joe once spoke of using the 1.5GHz Sandcraft CPU, but I can't remember now why he couldn't go anywhere
with it - probably needs the PROM source just like he does for the R9K/1GHz.

Ian.

Where is this PROM located physically?
Any chance to reverse-engineer it?

edefault writes:
> Where is this PROM located physically?

Mbd somewhere. Dallas chip or elsewhere I guess.


> Any chance to reverse-engineer it?

Unlikely. If there was, I'm sure Joe would already have done it.

Last year I did ask a couple of SGI people about releasing the PROM source; the response was, never gonna
happen. Individual SGI employees might think it's a neat idea (they did) but it's not up to them.

Ian.

pretty sure Jan-Jaap actually decompiled the PROM, IIRC the output came to 10MB or so. Next issue was, no-one knew what changes to make...that may have changed in the meantime.

Is that decompiled image available somewhere on the net?

PARADOX to the rescue

( Sorry, did I just say that?!?! <cough, cough> )

I'm not that stupid

Disassembly may be allowed where I live, but distribution of copyrighted material certainly isn't.

Obviously reverse engineering the PROM is the start, but the main problem is that I believe the datasheet/manuals for the chip used in a 600MHz O2 were only available via agreement from PMC-Sierra. I think Chicago-Joe was given them, but said he didn't have the expertise to change the PROM. And PMC-Sierra watermark PDFs with the account, company and date/time when you download them, so you wont just find it leaked on an FTP server somewhere.

That part even I could fix !

Well...With the Datasheets for the different TLB entries and a socket header/base pair from here

http://www.bgaadapters.com/bga2301.htm

specificially

http://www.bgaadapters.com/images/BGAH-304-2301.PDF

and

http://www.bgaadapters.com/images/BGA-304-2301.PDF

AND someone that could make the necessary changes to the PROM, safest would be to use the one of the redundant CPU's that are still in the PROM it's all do-able

Even Joe said he'd use one of the sockets for the experiment as it meant that you could get the RM7000c @600Mhz running to eliminate that one variable, then switch in the faster chip with the modified PROM. Part of the reason I think he gave up on the faster PMC-Sierra chips was the reliability of the CPU rework and the time/cost if it didn't work. At least with a socket setup you'd have a known working re-worked CPU module to begin with, then nail down the PROM changes to get it to boot.

I remember when he was in touch with PMC-Sierra, they said all the PROM needed was a couple of lines changed for the 900MHz chips. Apparently the only difference between the RM5200 & RM7000(A, B, C), and the RM7900 is the TLB entries, they are pin compatible otherwise.

My (possibly incorrect?) recollection of events was that PMC-Sierra originally claimed the chip was 100% software and pin compatible (just like the RM7000/600 is). So Joe created a test module, and it didn't work. He then said it was a software incompatibilty, and there was something in the PROM that needed to be changed to get it to boot, and that he knew the values needed (due to having access to the datasheet). I expect you would need it to definitively find out things like the PRid values, TLB entries, and to confirm things like cache instruction encodings and CP0 hazards are identical to the existing RM7000/350 (which would be the most obvious candidate for modification). And most importantly, MIPS chips often have model or even revision specific errata that might need workarounds.

I guess things would be much easier if there only were a socket for BGA305 CPU available,
which would allow to swap the processor without the heavy soldering ... is there eventually?

I´ll gladly donate some CPU modules that didn´t make it after soldering on a RM7000@600.

Walther

Check my earlier post, they are available here

http://www.bgaadapters.com/bga2301.htm

They've got sockets which are soldered to the board and another which is soldered to the chip

They're a press fit with pins from the header and CPU attached going into the socket on the board.

Not sure on the price though, but if you weigh up the cost of damaged CPU boards from failed swaps and the ability to go to the RM7900 if the PROM issues can be solved it might be worth it

Nekochan n00b greetings from a longtime Irix-o-phile (Indigo2 SI for the win), and recent (yesterday) O2 owner!

jan-jaap, or anyone else who knows: can you please recommend to me a place in the NL/BE/DE/FR area that is able to perform the necessary chip-swap work on an RM5200 board? I've found a PN# 030-1493-001 for OK-ish money online, but I want to be able to line everything up with a certain degree of surety first, rather than blowing money and hoping.

Oh and incidentally, my girlfriend is from Wijchen

'edefault' (see a few posts up) is the guy who has the parts to do the conversions on suitable RM5200 modules. He is based in Germany. Perhaps send him a PM.

We are currently trying to accumulate enough modules for a batch.

Ian.

Mine isn't

But I guess it means you're in the neighborhood often -- If you'd like to see a bit of SGI history, just PM me.

Spoken to edefault. You can count my module in...when I get it! For lack of a European supplier of RM5200 boards I'm having to order mine from California, which will mean it's at least a week before I have it.

Have received my 600MHz module and it's happily running with a fresh install of 6.5.30! Fantastic It booted once or twice on the 6.5.29 install I was running with my 180MHz R5k, but otherwise would fairly consistently hang during boot with the 600MHz module, and very consistently would boot with the 180MHz one. I mention this in case anyone else has a similar issue-- luckily as I have piles of SCA80 drives sitting around, reinstalling was pretty painless.