sgi/mips status

[ddc]

i was always thinking that

* o2-R10k/R12K
* fuel
* tezro

ware not supported machines cause of the unknown hw internals or such an issued stuff

well, i checked the openBSD page and i see this:
(http://www.openbsd.org/sgi.html)

[armanox]

i would guess that no progress takes place due to lack of hardware.

I had 2 SGI O2's, one with a R5k and the other with a 10k, both have since died. Guess back to beating the Octane.

[ddc]

?

my O2-R5000 is pretty running 2.6.24

anyway it seems *bsd guys have success, i have to verify by myself
(just asking my friend if he could let me try his fuel - R16-700Mhz with net/open/whatever-BSD)

[armanox]

[Kumba]

Linux on R10000/R12000 on O2 is tricky for a few reasons. The OpenBSD people worked around the issue because the OpenBSD memory code is a lot simpler, and some of the solutions that worked for the R10K issue on IP28 systems were easily adapted to this machine (I believe). Linux has a much more complex memory system, because of the various layers you have to allow the code base to build on as many different systems, architectures, and configurations as Linux is capable of these days, and the only two known ideas that might work, one of which has been tested somewhat, are:

- The same approach to IP28, where we use the R10K cache barriers capability available in GCC 4.4 to protect the code from the speculative execution issue present in these systems/CPU combinations.
- Leverage a feature only available on R12000 O2 systems called "Juice", which lets the CPU avoid this issue. I believe the knowledge needed to implement this completely is still locked away in lost/forgotten SGI internal documentation, but you can find references to it in the last known updated copies of the NEC MIPS Vr10000 processor manual, of which the R12000 is a member of.

I believe the approach the OpenBSD people took was the first, and because of the simpler nature of their distribution, writing up the needed cache support code was fairly easy for them I believe. I think for Linux, we'd have to model the IP28, protecting the network driver and SCSI drivers at minimum from the speculative execution issue, and that's not very easy to do, especially with a common driver that changes a lot like the aic7xxx used in O2 systems.


Octane:
I last played with this in 2.6.30-rcX, and was able to restore SMP support, but could not boot into user land. The INIT process segfaults as soon as it is executed, and I haven't had a lot of time to get back to it and try to figure out what's wrong. I currently have no time table on when I'll be able to get back to it either, so this machine is pretty much dead for the time being.

IP35-based hardware (Including Origin 300, 3000, Fuel, and Tezro):
There was some work done on booting Linux on the core hardware of this line, the Origin 300 system. If one pokes into the Linux MIPS Git repo, you'll find a tag in there for IP35 code. The catch, this code only boots the kernel. No userland support is available yet, and networking is dead because Ralf Baechle, who runs the Linux/MIPS port in the kernel itself, hasn't had a lot of luck decoding the MAC Address out of the EEPROM chip that these systems use. If Origin 300 can get up and running, it's theoretically possible that the other systems, Fuel especially, could be usable if someone had the hardware. Tezro might be tricky, as it's a pretty complex machine, but Origin 3000 support is unknown due to the scalability of those systems. Anyone whose ever tried getting Linux to play nice on old Origin 2000 hardware knows how difficult those systems can be to work right on Linux.

Not to mention the difficulty of finding these systems on eBay or such. The reseller market has a very high demand for old SGI equipment, which puts it out of reach of hobbyists who just want to hack on it for fun.
_________________
"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic

[ddc]