OpenBSD Journal

Heads up: New SGI hardware supported!

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


  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

  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

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


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)

  1. By Aaron Bieber (qbit) on

    Knew I should have kept my Indy!

    1. By Will Backman (bitgeist) on

      > Knew I should have kept my Indy!

      Me too. I threw them out this summer when I moved. SGI equipment is just too heavy to keep moving around.

    2. By Miod Vallat (miod) on

      > Knew I should have kept my Indy!

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

  2. By sneaker (sneaker) on

    Wonderful! Thanks!

    Can't wait to dust off my pizza boxen and indigo2.

  3. By Dimitri Sokolyuk (quax) on

    Great! Sadly my Indigo2 hangs right after `Found SGI-IP22, setting up.'

    1. By Miod Vallat (miod) on

      > Great! Sadly my Indigo2 hangs right after `Found SGI-IP22, setting up.'

      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.

    2. By Miod Vallat (miod) on

      > Great! Sadly my Indigo2 hangs right after `Found SGI-IP22, setting up.'

      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.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]