600MHz O2 Is Up And Running!!

SGI hardware problems, solutions, tips, hacks, etc.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
Richtom1
Posts: 798
Joined: Sun Oct 17, 2004 5:49 pm
Location: Florida

Unread postby Richtom1 » Sat Feb 05, 2005 5:46 am

I've heard it a few times too (inability to o/c an Indigo 2 Impact 10000). :cry:

Some of us can dream....can't we? Sometimes the mind can find a way to accomplish what was thought to be impossible.

The Barney-Box is one fine lil box and when fitted correctly will make believers out of some :shock: Richard

User avatar
edefault
Posts: 609
Joined: Fri Nov 28, 2003 6:02 am
Location: Germany
Contact:

Unread postby edefault » Tue Feb 08, 2005 4:09 pm

hamei wrote:the Barney-box is a damned nice computer. You can put a gig of memory into one. The drives are a tad slow but stick all the working data into memory ... scrounge up some video options, get a MaxImpact boardset and a faster ethernet card and with a faster cpu it would be a *very* nice toy


hamei: please apologize - I didn´t mean to insult what you call the Barney-box.
I have some (5) myself and these ones are my real workhorses:
1GB RAM, Phobos G160 and bigger - and pretty silent - IBM disks, DVDROM...
Btw., the MaxImpact gfx performance for CAD is still convenient.
I have worked on "modern" wintel machines which run ProE not noticeably faster than an Indigo2 R10kMI.

IMO these "Barney-Boxes" are among the finest computers ever built,
and I would sure _love_ to see something similar to Joe´s O2@600 speedup.
But we´re stuck with 200 until some hardware guru offers third party CPU boards.
Besides, I´m not sure if the bottleneck FSB (or SCSI or whatever) would allow a faster CPU to increase the overall performance.

My favourite Indigo2 is one with a retro _teal_ case, though (R10k@195 anyway), not purple.

hamei
Posts: 9986
Joined: Tue Feb 24, 2004 5:10 pm
Location: over the rainbow

Unread postby hamei » Tue Feb 08, 2005 8:13 pm

edefault wrote: hamei: please apologize - I didn´t mean to insult what you call the Barney-box.


Hey ! no need for apologies. If we can't banter a little then life would be no fun, yes ?

IMO these "Barney-Boxes" are among the finest computers ever built,
and I would sure _love_ to see something similar to Joe´s O2@600 speedup.
But we´re stuck with 200 until some hardware guru offers third party CPU boards.
Besides, I´m not sure if the bottleneck FSB (or SCSI or whatever) would allow a faster CPU to increase the overall performance.


Yeah, everything else in the box is a smidge slow, too. Especially the scsi bus ... but my guess is you'd see speedups for little tasks that don't need to go to disk, similar to what you get on a peecee. Okay, an older peecee :) That'd be okay by me. Anything you can speed up is good ! (Except for MTBF)

AvidReader
Posts: 20
Joined: Mon Dec 27, 2004 9:37 pm
Location: USA, Colorado

chicago-joe Where are you

Unread postby AvidReader » Fri Mar 04, 2005 9:16 am

I have been watching these posts with baited breath. Is there any new information on the other tests?

User avatar
jan-jaap
Posts: 4007
Joined: Thu Jun 17, 2004 11:35 am
Location: Wijchen, The Netherlands

Unread postby jan-jaap » Fri Jun 03, 2005 3:51 am

So, I loaded a captured O2 PROM image in gxemul and disassembled it.

There are exactly 16 locations where it reads the processor ID. I didn't read all of the disassembly (there's about 11MB of listing) , but, for example, near the start it sets up the TLB, primary and secondary caches like this:

Code: Select all

read PrID
if (RM5200)
  do something
else if (!RM7000)
  do something_else

/* fall through, RM7000 setup */

something:
  /* RM5200 setup */

something_else:
  /* R5000, R10k and R12k setup */


While I found it amazing that R5000 and R10k are treated similarly, while RM5200 and RM7000 are treated separately, the fact remains that the O2 was released with R5k and R10k, and support for RM5200 and RM7000 came later.

PrID's for a bunch of CPU's can be found here. The R10k manual mentions it here. The instruction (mfc0) is privileged (kernel mode only) so you can't write a small program to mess with it, even if you run it as root.

Anyway, here's the clue:

IF the RM7900 is functionaly compatible to the RM7000 (and I read somewhere in this thread it is, but didn't check this myself), AND somebody can figure out the processor ID of an RM7900, then you could patch a PROM binary, replacing all occurences of RM7000 with RM7900.

Now,
1) Some other things may need changing, like the divider between CPU and SysAD, cache etc, this is a separate issue and has nothing to do with the PROM (?). Chicago-Joe knows the works.

2) Where I live, disassembly is legal (at least, for the time being). I know other countries have more retarded laws so I won't post disassembly listings here. PM me :-)

3) Standard disclaimer: if you destroy your PROM, your O2 may be for the junk.

So, what do you guys think, is any of this helpful to make the pipedream of 900MHz O2's come true?
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

User avatar
ruckusman
Posts: 401
Joined: Sun Jan 11, 2004 8:15 am
Location: Australia

Unread postby ruckusman » Fri Jun 03, 2005 6:59 am

This is exactly what we needed to know, pure genius on your part

Now one thing that I know we do need is the TLB entries, I contacted PMC-Sierra a couple of times to tyry and get the full spec sheet on the RM7900. They never got back to me, I do know for a fact that Chicago Joe has the needed data, but had to sign a non-disclosure statement, whether or not the info we need is included in that is another question.

I'm going to to try and figure out whether or not a PROM can be re-programmed if we kill one, I've got acces to an EPROM programmer, so it may be possible to salvage and incorrect PROM flash if the board won't boot.

I'm excited...

Glenn

User avatar
chicago-joe
Posts: 324
Joined: Fri May 09, 2003 9:01 am
Location: Chicago, IL
Contact:

Unread postby chicago-joe » Fri Jun 03, 2005 7:38 am

jan-jaap wrote:
While I found it amazing that R5000 and R10k are treated similarly, while RM5200 and RM7000 are treated separately...

The R10K/R12K use a kludged L2 cache system to make it look the same as the RM5xxx cache to the PROM and IRIX. The RM7000x chips are different because PROM/IRIX has to initalize the "on chip" L1 and L2 cache and the "off chip" (L2 on RM5xxx chip) L3 cache.

I do have the PrID for the RM7900 chips, it is at home (and I'm at work), I'll post it later this evening. The CPU ID information is not part of the NDA.

There may be an L2 cache initalization issue (I don't remember if it was the SandCraft chip or the RM7900 chip), but the L2 can be disabled for now to see if the system would come up at 900MHz.

BTW - Great work on the O2 PROM guys. :D

Joe

hamei
Posts: 9986
Joined: Tue Feb 24, 2004 5:10 pm
Location: over the rainbow

Unread postby hamei » Fri Jun 03, 2005 9:01 am

chicago-joe wrote:... but the L2 can be disabled for now to see if the system would come up at 900MHz.


900 mhz O2 ... yeeHAWWWW !!!!

Timberoz
Posts: 284
Joined: Fri Apr 25, 2003 8:06 pm
Location: Brisbane Australia
Contact:

Woo Hoo

Unread postby Timberoz » Fri Jun 03, 2005 7:42 pm

TURB-O2 @ 900mhz "Hold On Tight" :shock:

Timberoz> Craig

User avatar
colin
Posts: 453
Joined: Sat Feb 07, 2004 6:43 pm
Location: Lubbock, Texas
Contact:

Unread postby colin » Mon Jun 06, 2005 12:22 am

Where do I sign?

User avatar
chicago-joe
Posts: 324
Joined: Fri May 09, 2003 9:01 am
Location: Chicago, IL
Contact:

Unread postby chicago-joe » Mon Jun 06, 2005 11:01 am

OK, here we go:

The PRId is in CP0 register set 0, register number 15.

This is a 32 bit register, of the 32 bits, the Imp (implementation number) field is bits 8 through 15. The value for the RM7000x cpu chip is 0x27, the value for the RM7900 chip is 0x34.

Joe

User avatar
warerat
Posts: 75
Joined: Sun Oct 12, 2003 9:17 pm
Location: Texas

Unread postby warerat » Mon Jun 06, 2005 4:25 pm

ruckusman wrote:This is exactly what we needed to know, pure genius on your part

Now one thing that I know we do need is the TLB entries, I contacted PMC-Sierra a couple of times to tyry and get the full spec sheet on the RM7900. They never got back to me, I do know for a fact that Chicago Joe has the needed data, but had to sign a non-disclosure statement, whether or not the info we need is included in that is another question.

I'm going to to try and figure out whether or not a PROM can be re-programmed if we kill one, I've got acces to an EPROM programmer, so it may be possible to salvage and incorrect PROM flash if the board won't boot.

I'm excited...

Glenn


Isn't the flash chip located under the Dallas chip on the O2 (Mine's a Atmel AT29C040A)? It would be a "one-shot flash and cross your fingers that it works" unless you had a way to program it in-circuit or got some kind of surface-mount socket you could put it in to make it recyclable on a programmer...

User avatar
nekonoko
Site Admin
Site Admin
Posts: 8015
Joined: Thu Jan 23, 2003 2:31 am
Location: Pleasanton, California
Contact:

Unread postby nekonoko » Mon Jun 06, 2005 4:33 pm

warerat wrote:Isn't the flash chip located under the Dallas chip on the O2 (Mine's a Atmel AT29C040A)? It would be a "one-shot flash and cross your fingers that it works" unless you had a way to program it in-circuit or got some kind of surface-mount socket you could put it in to make it recyclable on a programmer...


Well if you only modify the RM7000 parameters the R5000 initialization code should still work - those CPUs are a dime a dozen and they'd be good enough to get the machine back into a state for a reflash. Unless I'm totally misreading things :)
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.

User avatar
jan-jaap
Posts: 4007
Joined: Thu Jun 17, 2004 11:35 am
Location: Wijchen, The Netherlands

Unread postby jan-jaap » Tue Jun 07, 2005 2:58 am

chicago-joe wrote:OK, here we go:

The PRId is in CP0 register set 0, register number 15.

This is a 32 bit register, of the 32 bits, the Imp (implementation number) field is bits 8 through 15. The value for the RM7000x cpu chip is 0x27, the value for the RM7900 chip is 0x34.


Yep, that matches my findings. Here's an annotated fragment:

Code: Select all

00000000bfc019d8: 40087800      mfc0    t0,prid     # read processor ID
00000000bfc019dc: 3108ff00      andi    t0,t0,0xff00
00000000bfc019e0: 00084202      srl     t0,t0,8
# PrID bits 8:15, values possible in O2:
# 0x23: R5000
# 0x09: R10000
# 0x0e: R12000
# 0x28: RM5200
# 0x27: RM7000
00000000bfc019e4: 1109003f      beq     t1,t0,0x00000000bfc01ae4
00000000bfc019e8: 00000000      nop
00000000bfc019ec: 24090028      addiu   t1,zr,40    # RM5200
00000000bfc019f0: 1109003c      beq     t1,t0,0x00000000bfc01ae4
00000000bfc019f4: 00000000      nop
00000000bfc019f8: 24090027      addiu   t1,zr,39    # Not RM7000
00000000bfc019fc: 1509006f      bne     t1,t0,0x00000000bfc01bbc
00000000bfc01a00: 00000000      nop

(TLB setup for RM7000 follows)

The idea is that if the RM7900 is functionally identical to the RM7000, one could simply patch the appropriate byte(s) in, like this:

Code: Select all

00000000bfc019f8: 24090034      addiu   t1,zr,52    # Not RM7900

The "functionally identical" is the big "if", of course.

nekonoko wrote:Well if you only modify the RM7000 parameters the R5000 initialization code should still work - those CPUs are a dime a dozen and they'd be good enough to get the machine back into a state for a reflash. Unless I'm totally misreading things :)


In theory, you're absolutely right. Just don't shoot me if you destroy your O2 because I overlooked something. Of course, if the RM7900 is not functionally identical to the RM7000, you're looking at a different problem. You'd have to write TLB and cache setup code and inject it into an existing PROM. Tricky business.

There's another issue, and that's flashing the modified image into the O2.
It seems like the first 0x100 bytes of the ip32prom.image are some sort of header, followed by the actual PROM image. In my case, I dumped the O2 while it was running 6.5.23, upgraded to 6.5.27 and then compared the dump to ip32prom.image, and I noticed differences after 0x100. Me bad, I'll have to dump it again because it did flash it during the upgrade, even though the version is still 4.18, dated 2002. :? Anyway, this first 0x100 bytes probably contains checksums that won't match if you patch the image.
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

User avatar
edefault
Posts: 609
Joined: Fri Nov 28, 2003 6:02 am
Location: Germany
Contact:

Unread postby edefault » Tue Jun 07, 2005 10:43 am

Just curious:

is anybody planning to exchange a R5200 CPU with a R7900 to see if a patched PROM image will work?

And if yes, when eventually?

I have a dozen O2 CPU modules - three of them R7000 ones - in the process of being reworked for 600MHz after ChicagoJoe´s recipe,
but these are still sitting and awaiting components... so it might be of interest.
Perhaps we´d to decide to go straight through and order R7900 CPUs instead?
(OK, just dreamin´)

Walther


Return to “SGI: Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests