Contributed by maxime on from the we-build-better-dinosaurs dept.
Miod Vallat (miod@) has just posted a message on the sgi@ mailing list to give the world some news about the OpenBSD SGI port: the IP20, IP22 and IP24 SGI systems (also known as Indy and Indigo, true classics) are now officially supported on -current!
Please see below to read Miod's words:
Subject: Support for R4k Indigo, Indy and Indigo2 added From: Miod Vallat
Date: 2012-04-24 21:58:40 Hello, I am happy to announce that the current snapshots of OpenBSD support the IP20, IP22 and IP24 SGI systems. In other words: - R4000 and R4400 Indigo (IP20) - R4000, R4400 and R4600 Indigo2 and Challenge M (IP22) - all Indy and Challenge S (IP24) I know that several (many?) of you had been asking in the past, and I had always intended to work on this (didn't I get an R4000 Indigo, 12 years ago, for this purpose?). Wait no more! This has eventually happened. This work was helped by the existing NetBSD work, which provided basic device support (serial, Ethernet and SCSI). Of course running these systems in 64-bit mode opened quite a large Pandora box-of-problems, but we have reached a point where the system is running stably and able to rebuild itself. Oh, did I mention that I stumbled onto a few hardware bugs, such as extremely important device registers not always returning their value when being read? Anyways, what this really means is that you can wipe the dust off your system, plug it back, boot the OpenBSD installer and get a working system in less than half an hour (unless there really is a lot of dust to clean first). There are still a few rough edges, though. What works: - onboard serial, keyboard/mouse, SCSI and Ethernet controllers. Tested and confirmed to work. - all frame buffers are supposed to work, at least in console mode. However, only Newport (XL/XGE, found on Indy and Indigo2) and Express/Ultra (XZ/Elan/Extreme, found on Indigo, Indy and Indigo2) have been tested. The Light/Entry/Starter graphics on Indigo, as well as Impact on Indigo2, ought to work out of the box, but could not be tested (donations welcome). There is no X11 server for any of these frame buffers yet. - GIO E++ boards work. GIO32 SCSI boards ought to work too, but could not be tested. - the Challenge S second Ethernet interface (on the IO+ mezzanine) ought to work. What doesn't work (yet): - the extra SCSI controllers (WD33C95) on the Challenge S IO+ mezzanine are not supported (anyone got a Challenge S to spare?) - Fast Ethernet GIO options (Phobos G130 and G160, as well as `Set Engineering' Fast Ethernet are not supported. There is code to borrow from NetBSD, but it's not really an option without access to the hardware. - on-board audio on Indigo (hdsp) and Indy/Indigo2 (haltwo). - on-board parallel port (honestly, I couldn't care less). - L2 cache on R4600SC and R5000SC processor modules. I am working on this, but need to introduce a few interfaces first, and this takes time checking I do not break other systems. Coming soon. What sort of works: - the EISA bus on the Indigo2 attaches and cards get detected. However I have only been able to test it with 3Com ep(4) boards; the 10MBit/s models have abysmal performance, and the 100MBit/s 3C597 (or Phobos G100) doesn't seem to interrupt. Your mileage may vary. Snapshots are available from OpenBSD FTP mirrors near you; do not hesistate and play with them! However, please, please, pretty please, do not expose an R4000 or R4400 based system to the internet. These processors suffer from unfixed errata which can be used by local users to gain supervisor privileges. On these systems, you can't trust your local users - at all. As in, never give me a shell access to the system or I'll root it without even thinking. R4600 and R5000 based systems do not suffer from such problems. If you have an early R4000 processor (either an 1.x or 2.x version), other bugs will prevent it from running stably (the so-called ``end of page'' bugs). The system will run multiuser, but from time to time, some processes will misbehave. My own Indigo has a revision 2.2 R4000, so I am experiencing these issues first hand (and this system is currently not able to rebuild itself because of these processor bugs). However the processor errata documentation is public, and I am working on designing a good way to circumvent them (and it's no easy task, especially with the goal of not affecting the performance of other processors). But enough said. The real reason for this work was to get good device support, in order to be able to port OpenBSD to the Power Indigo2 systems: both the R8000 flavour (IP26) and the R10000 flavour (IP28). Those systems come with a specific memory controller which needs some care in order to operate properly; and of course the R8000 processor is an odd beast which, to this day, is not supported by any free operating system. I would like to change this state of things, and have IP26 and IP28 systems be able to run OpenBSD, if only for the sake of it and the joy of getting my code to run on formerly unsupported hardware. Unfortunately, I do not own any such system - neither an R8000 Indigo2 nor an R10000 Indigo2. If you know of such a system collecting dust, which owner would not mind parting of, please let me know. I'm sure we can arrange something. Miod PS: If you only have R4k ``PC'' processors, that is, without a secondary cache... then do yourself a favour and don't try to compile anything on them... these small caches get blown a few orders of magnitude by gcc 4 when compiling even the smallest program. This is very hard on the R4000PC systems, which only have 2x8KB cache (I have such a system, it's perfectly stable but glacial as soon as you are compiling anything on it). R4400PC, R4600PC will be a bit more bearable because their cache is twice larger.
Now you can visit want.html to fill Miod's home with more and more hardware so he can port OpenBSD on it!
(Comments are closed)
By Aaron Bieber (qbit) firstname.lastname@example.org on http://qbit.io
By Will Backman (bitgeist) on http://bsdtalk.blogspot.com
Me too. I threw them out this summer when I moved. SGI equipment is just too heavy to keep moving around.
By Miod Vallat (miod) on
On the other hand, if your remembrance of the Indy is how you experienced it 20 years ago, it is probably better to no longer have it. These machines were fast and awesome. Nowadays they are slow and below average.
Not that I mind anyway...
By sneaker (sneaker) email@example.com on
Can't wait to dust off my pizza boxen and indigo2.
By Dimitri Sokolyuk (quax) firstname.lastname@example.org on http://www.dim13.org/
By Miod Vallat (miod) on
Please mail me details about your configuration (an `hinv -v' from IRIX or from the PROM will do), as well as whether you are using glass or serial console.
By Miod Vallat (miod) on
You probably have an Impact Indigo2. This has been fixed a few days ago, and the upcoming sgi snapshot will run correctly on Impact systems.