The collected works of rumble

badapple wrote:
Although only the O2 is currently supported, there are some recent commits for IP30 and IP27 and IP35 is being worked on too. Backwards support for IP22 doesn't seem to be that much of a priority looking at the thread, which is a shame - I'm happy with Irix on the faster machines but OpenBSD is increasingly useful on many older architectures as an alternative to linux. It's already effectively superseded linux on sparc32 now that nearly everyone has dropped support, and I'd really like it as an option on my older MIPS stuff, like the Indy currently running Debian under my desk. OpenBSD 4.3 is looking very promising.


NetBSD has support for IP6, IP10, IP12, IP20, IP22 and IP32. OpenBSD supports more of newer machines, Linux has some IP26 and IP28 (along with IP22, IP32 and IP30?) support, and Russ Cox's Plan9 sources contain SGI Power code. Graphics aside, the opensource world supports most of the SGI machines already. The graphics being the most interesting part in most cases, the allure of IRIX will remain unparalleled, but for the server-class or headless machines, there's plenty you can still do with them -- even a 4D/20 will run the NetBSD-current ;)

It would be nice to see this all consolidated a bit, though. Maybe someday the OpenBSD guys will import the support NetBSD has for the older machines, or the other way around.
mapesdhs wrote:
Alas, without the PROM source, not gonna happen.


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.
bri3d wrote:
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.


The problem is that the kernel is likely not to work for the exact same reasons the PROM won't. Why should we expect the IRIX IP32 kernel to know how to deal with the peculiarities of the new core if the PROM doesn't? In fact, I imagine there's more room for concern as the PROM uses far less CPU functionality than the kernel does.

bri3d wrote:
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.


That's why we run it in gxemul and see what it does. I'm guessing this part isn't quite as difficult as you imagine.
mapesdhs wrote:
rumble writes:
> Lack of PROM source probably isn't the problem so much as the inability to alter the IRIX kernel is.

Nope, according to Joe, we DO need the PROM source.


And I'm saying that we do not. Why would we if we could roll our own? I'm not convinced by unsubstantiated appeals to authority.

mapesdhs wrote:
> think it'd be reasonably straightforward to create a workable replacement that could load a Linux or BSD kernel.

Who the heck cares about Linux or BSD on O2? IRIX rules on this system. Otherwise, it's just a generic box. *yawn*

> ... but you can kiss running IRIX goodbye.

Boring IMO. More pointless than a fart in a thunderstorm.

Ian.


Opinion. Running IRIX is pretty pointless, too, is it not?
I see what you mean, but I still don't believe that it would be so difficult. Setting up such state isn't magical (assuming there are docs for the CPU), it's just tedious. Heck, this topic is covered for the R3k in about 20 pages in The MIPS Programmer's Handbook.

My point is simply that the IRIX kernel is very unlikely to support this new core unmodified and that this could well prove a more substantial task than getting around the PROM limitation. Though who knows? Perhaps we'd only need to patch up the Processor ID check somewhere if the cpu is binary compatible with some already existing cache/tlb/etc configuration. Plus, symmon makes debugging much easier.

Anyway, I'm much less pessimistic that this couldn't be done. I messaged ChicagoJoe a year or two ago to inquire about the more recent chips he had soldered, but never heard back. I guess we'll never know.