Nekochan Net

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

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 Richard

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.

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



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)

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

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:



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: (2x)
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

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

jan-jaap wrote:

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.

Joe

900 mhz O2 ... yeeHAWWWW !!!!

TURB-O2 @ 900mhz "Hold On Tight"

Timberoz> Craig

Where do I sign?

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

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.

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

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

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



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: (2x)
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

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