Hardware For Sale/Trade

Ok, so this one:

http://www.allegro.pl/item790626436_mac ... _2_gb.html

will work as JBOD with normal drives without flashing, yes?

Does anyone now if this a dual active loop array?

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.

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.


> 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.

I don't think he's claiming it's unneeded, just that the IRIX kernel poses a larger problem.



I do, but this is really a different topic.

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.



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.

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.



Opinion. Running IRIX is pretty pointless, too, is it not?

Actually the PROM is likely to be far trickier than the kernel. When PROM on a MIPS CPU gets control at the boot vector, the cache is in a completely undefined state (as is the TLB). So even things like cache line address tags, state and check bits and config registers may have garbage values. It has to completely initialise it to a point so that it is possible to even enable the cache without causing errors. So the PROM is working with the cache hardware at a much closer level. Much of the initialisation is already done by the time a kernel gets control, the idea being that it can then just query the PROM config tree to find out about the cache and just handle normal synchronisation during page mapping changes, DMA etc. While the kernel isn't immune from changes in cache hardware (depending on how it is written obviously), it is less tied to it than the PROM is.

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.

MIPS isn't the worst of CPUs thankfully, but cache code is quite intricate stuff at times (I've written some). Bugs can be very tough to pinpoint and track down. Of course it mainly depends on how ambitious people may get trying to shoehorn in new CPUs with specs that vary a lot from those originally supported in O2 + IRIX.

And sometimes it does involve magic Look in Linux from a few years ago and you might find a comment warning people "not to even breathe" on the cache initialisation code (because it was so hard to get right).


Things evolved a little since the R3k I dont have any R3k book anymore, but I think it had physical indexing and tagging, direct mapping and was write through, which was about as simple as cache hardware gets. The RM7k series supports a split onboard L1 cache, joint onboard L2 cache, and off chip L3 cache.


Yes. As long as things are kept similar to existing models, then it could be doable. That is probably why the 600MHz model worked so well. But AFAIK the faster CPU's Joe tried were supposed to be binary compatible as well, yet they didn't work.

rumble writes:
> 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.

In that case, feel free to try.


> Opinion. Running IRIX is pretty pointless, too, is it not?

Blatantly no because that's the only and sensible way to exploit the hardware accelerated and full
functionality of an O2.

Ian.

Three drives left...