Yeah, a new board would be cool if possible, and maybe make it easier to offer larger L2/L3?

hamei wrote:The prom data would make this a real winner tho. I myself am kind of iffy at 600 but 900 ... I know, performance is not all about processor speed but still ...

Joe & I had originally hoped to offer a 1.5GHz module with 16MB L2. That was our initial plan. Then the Sandcraft chip didn'tseem so much like it would be possible, so we aimed for 900MHz. Note the L2 was to be 50% faster than normal (IBM told Joethis was important to help match the faster CPU clock). Alas, without the PROM source, not gonna happen.

In response to you request to release the prom code, our position is unchanged. Similar toIntel's treatment of PAL as a micro-architecture extension of their processor, SGI managesPROM source as strictly proprietary and any release to the public domain is not an option.

Sorry guys...

Ian.

PS. I have a slightly different theory. I don't think they even have the PROM source anymore. My guess is the dev systemshave long since gone, ditched during shakeouts, Chap11, buyout, etc. I know the ICE-dev systems went long ago.

Since it's proprietory code, why not? Doesn't make any difference anyway; far as I can tell, it's just not going to happen.

Ian.

I'm working on a charitable PC build for the Learn Engineering YouTube channel. Please PM/email/call if you'd like to contribute!Donations of any kind of item I can sell to provide funds are also most welcome.mapesdhs@yahoo.com+44 (0)7434 635 121

mapesdhs wrote:PS. I have a slightly different theory. I don't think they even have the PROM source anymore.

That code is closely related to the IRIX kernel code, and some bits are shared between kernel and PROM. I don't think they lost it, but I understand they have issues releasing it

mapesdhs wrote:

mattst88 wrote:Beyond that, I doubt the own all the PROM source.

Since it's proprietory code, why not?

Propriety has little to do with it. If part of the PROM code is licensed by SGI from a 3rd party, they don't own the copyrights and they they cannot just release it without permission. In the case of the PROM code one such party is almost certainly MIPS. The first CPU boards in the Professional Series were basically OEMed from MIPS, including the PROM, and later IPxx boards were derived from those.

But unfortunately you're certainly right when you say this isn't happening. They will bury every last bit of it, and the IRIX code, rather than releasing it. Sad but true.

ShadeOfBlue wrote:How about disassembling the PROM, rewriting the CPU initialization code and then reassembling it?

I did that for some of the early systems like IP7 and IP12 and it is a monumental task. There is little reward because you cannot publish your results. I did it because I wanted to learn about the PowerSeries at the very lowest level.

99% of the PROM was originally written in C, so it's not just a matter of disassembling, you basically have to rewrite the matching C code. For a later, much more sophisticated system like an O2, it's not something I would consider doing.

Oh, and I no longer have a computer with the IDApro license, so while I still have the IDA data files they are now useless

To accentuate the special identity of the IRIS 4D/70, Silicon Graphics' designers selected a new color palette. The machine's coating blends dark grey, raspberry and beige colors into a pleasing harmony. (IRIS 4D/70 Superworkstation Technical Report)

Its also possible that Microsoft indirectly did some of the SGI PROM development, as they were a major member of the ARC development consortium when originally targetting MIPS boxes with NT (and ARCS seems to be a derivative of ARC). Also, Microsoft were involved closely with MIPS (the company) because the Jazz design used by MIPS Comp. was licensed from them.

There is nothing simple about disassembling and modifying a PROM image either. Cache management is one of the trickiest pieces of code to write normally, let alone disassemble and make fundamental alterations to. And I don't expect many people here have the necessary spec sheet and errata info to write code for these 900MHz+ MIPS CPUs anyway.

kramlq wrote:... And I don't expect many people here have the necessary spec sheet and errata info to write code for these 900MHz+ MIPS CPUs anyway.

Joe said he could do it but only if he had the original PROM source. He was offered kind help from PMC and Sandcraftin this regard should the opportunity arise, and IBM gave him some tech help aswell on cache issues. It's perfectly doable,but for the PROM source. Ah well, plenty of other SGI-related things to occupy our time...

mapesdhs wrote:Joe said he could do it but only if he had the original PROM source. He was offered kind help from PMC and Sandcraft in this regard should the opportunity arise, and IBM gave him some tech help aswell on cache issues. It's perfectly doable, but for the PROM source. Ah well, plenty of other SGI-related things to occupy our time...

I wonder what they hope to achieve by this dog in the manger attitude ? I don't mean "release the code ! Free Prommy !" I mean qualified people who are willing to sign non-disclosures. It's a small amount of effort for them in return for a reasonable gain. Yeah, I know, "if it doesn't help the bottom line then in today's economy they can't afford to waste their efforts."

Except it's a helluva lot different story when they want acceptance from the Linux community, when they want to shitcan all the people who paid good money for Irix, when they want something requiring good will and a positive attitude and unpaid efforts from other people (such as a complete free operating system which they planned to use for their own financial advantage, ahem.)

Maybe I'm an idiot optimist. I'd like to believe until proven wrong that the new management is not quite as avaricious and short-sighted as the previous group of proven fools. Perhaps some people inside the new SGI can see the value in having enthusiastic hobbyists doing things to enhance the SGI mystique and reputation.

kramlq wrote:... And I don't expect many people here have the necessary spec sheet and errata info to write code for these 900MHz+ MIPS CPUs anyway.

Joe said he could do it but only if he had the original PROM source. He was offered kind help from PMC and Sandcraftin this regard should the opportunity arise, and IBM gave him some tech help aswell on cache issues. It's perfectly doable,but for the PROM source. Ah well, plenty of other SGI-related things to occupy our time...

Ian.

Yes, but what I mean is that anyone who decides to disassemble and alter the PROM would also have to get the CPU spec sheets via ahem... unofficial channels. If you were to get official access to the CPU specs (e.g. signing an NDA or whatever), and then a few weeks/months later support for that CPU mysteriously gets added into the O2 PROM via reverse engineering .... well it kind of narrows down the field a little if SGI wanted to defend their code/intellectual property rights.

Anyway, there are plenty of RM7000C-600T bare CPUs available in china I managed to get me a tray of these (27) and can offer more 600MHz rework.

For all who don´t know: *only* R5271 O2 CPU modules are suited for this.No, I do *not* have complete modules for sale - these babies are rare

But I do have some O2 600MHz modules which behave quite strange!E. g. one does pass all IDE tests (invoked from PROM monitor, lengthy!)without a single error message, but IRIX boots directly into shutdown:from "stop for maintenance" into "ok to power down", nothing in between.

Valueing life is not weakness; disregarding it is not strength. -Mirage-

Lack of PROM source probably isn't the problem so much as the inability to alter the IRIX kernel is.

With a combination of disassembly, IRIX/Linux/OpenBSD/NetBSD headers, and examining the existing PROM as it runs through gxemul, I think it'd be reasonably straightforward to create a workable replacement that could load a Linux or BSD kernel.

So, if you have hardware you know (or are very confident) works, I don't think it would be too difficult, but you can kiss running IRIX goodbye.

The first step would be figuring out how to rescue a botched PROM. I'm quite certain there's an emergency means of flashing that thing via the serial port, though when I explored this a few years ago, I got the impression that although the flash chip could have portions permanently write-protected, it didn't appear that SGI used that functionality. They seemed to make cache assumptions in the very lowest-level code (which would presumably incorporate the rescue feature), making it necessary to flash the whole thing with the introduction of a new CPU.

Lack of PROM source probably isn't the problem so much as the inability to alter the IRIX kernel is.

With a combination of disassembly, IRIX/Linux/OpenBSD/NetBSD headers, and examining the existing PROM as it runs through gxemul, I think it'd be reasonably straightforward to create a workable replacement that could load a Linux or BSD kernel.

So, if you have hardware you know (or are very confident) works, I don't think it would be too difficult, but you can kiss running IRIX goodbye.

The first step would be figuring out how to rescue a botched PROM. I'm quite certain there's an emergency means of flashing that thing via the serial port, though when I explored this a few years ago, I got the impression that although the flash chip could have portions permanently write-protected, it didn't appear that SGI used that functionality. They seemed to make cache assumptions in the very lowest-level code (which would presumably incorporate the rescue feature), making it necessary to flash the whole thing with the introduction of a new CPU.

An IRIX kernel wouldn't need alteration to run with a custom bootloader - once you've got the hard part (bringup) done I am fairly sure loading sash is a matter of read and jump.

CPU/bus/co-processor bringup (the part we'd need to change) would be the challenge - to the best of my knowledge, no open-source code can do it - we have knowledge of how to bit-bang the hardware once it's up, from Linux and NetBSD folks, but I don't think anyone's worked out how to bring it up at the low level. Considering the wide variety of goofy hardware inside the O2, I think bringup might get pretty involved.