(Follow this link to go back to the main SGI page.)
Before I start narrating the tale of BSD on MIPS in general and of OpenBSD on SGI in particular, you might want to familiarize yourself with SGI hardware over the years.
An excellent resource about SGI systems, from the early Motorola 68000-based IRISes to the latest Itanium-based Altix, can be found on Gerhard Lenerz' sgistuff site.
In this narration, I will focus on only a subset of the MIPS-based systems. You might want to keep an eye on the timeline page as well.
In the beginning of this story, the most iconic SGI systems are the Indigo (the Song and Dance machine, as was silkscreened on some of its boards), first released in 1991, which is getting replaced by the Indy, SGI's first workstation in pizzabox form factor, and the Indigo2, a larger desktop case which can also be put deskside with special feet, and has more expansion capabilities than the Indy.
All these three systems have nice coloured cases, with a dark blue (well... indigo) for the Indigo, a clear blue for the Indy, and a clear teal for the Indigo2 (some later Indigo2 models will sport purple cases). This is quite the eye catcher, in a world where workstations tended to be greyish (with some subtle lavender touches on Sun Aurora case used by the SPARCstation 20, 5 and 4) or beige, just like the average PC clone case.
Another distincting feature of the SGI systems is that, when powered on, they would play a short tune, different on every model.
(You can find decent recordings of some of these sounds on YouTube. Interestingly, despite not having an internal speaker, the Octane nevertheless has its own boot tune, but to hear it, you need to plug external speakers or headphones into the rear jack.)
This made these workstations really appealing. Which is the #1 reason why people have wanted to run BSD or Linux on them. Not only because it could be done, but because these machines were the raddest.
In late 1996, the O2 was introduced to replace the Indy as the entry-level workstation, and shortly after, in early 1997, the Octane was introduced to replace the Indigo2. Both systems would now use PCI cards for expansion, with the O2 having one PCI slot for a short card, and the Octane having an optional PCI cardcage allowing for up to 3 cards of any length. Both these systems carried on with the coloured case tradition, the O2 being dark blue, and the Octane green, but one surprising feature was that the top of their cases were rounded, and it was no longer possible to put anything on them (and definitely no 21" CRT monitor, despite the Octane chassis being strong enough to support its weight.) The Octane, despite being larger and wider than the O2, had no internal 5"1/4 storage device bay, requiring external SCSI CD-ROM drives, while the O2 came with a CD-ROM drive at the top of the case.
The Octane was also a multiprocessor capable machine, allowing for up to two processors; customers needing more could buy the Origin 200, introduced at about the same time; each Origin 200 system would have two processors, but two Origin 200 systems could be connected with a so-called NUMAlink cable, to create a four processor machine. And if you had needs for even more horsepower, the Origin 2000 family could easily allow for up to 128 processors, as long as you could afford them (and the electricity bill.)
(SGI marketing department even had five Octane-related songs recorded and burned onto an audio CD given away to prospective customers; these songs are not that bad and will probably make you smile. You can find decent quality mp3 files for them here.)
The Origin 2000 and 200 families were improved with the Origin 3000 and Origin 300 lines in 2000 and 2001, with twice as many processors per node (a single Origin 300 node would now have four processors). Then in 2002, these were improved again with the Origin 350 and Origin 3500 families, and the single-processor Fuel system intended to replace the Octane (although, with one processor and only up to 4GB of memory, it was behind the best Octane configurations, which could use two processors and 8GB of memory), and some reliability problems in the early models quickly earned it the Fool nickname.
The Fuel systems also stood apart from the rest of the SGI systems because of their case colour; they were initially supposed to sport a nice blue colour, and the Fuel prototypes did; but once marketing settled on the name Fuel (the codename for that machine had been Asterix until then), it was obvious the case colour had to match with the implied fire capability of the name, and it was changed to a bright red, which would remind old-timers of the SGI Crimson.
This is a very quick description of the SGI workstations, and to sum things up:
But eventually, OpenBSD ran on (almost) all these machines.
The first bits of MIPS code were written by Ralph Campbell of the University of Utah, starting in 1988, but weren't contributed to the CSRG at the University of Berkeley until early january 1992, where Kirk McKusick commited the code with a simple ``contributed by Ralph Campbell'' log message.
This code was attempting to get BSD to run on the original Digital DECstations, models 2100 and 3100, also known as pmax. In the beginning, this was just the kernel, with the userland being the Ultrix binaries. But work on native userland binaries followed, with the first commits occurring that same year on february 29th, by Ralph Campbell himself, who had received access to the CSRG source code repository.
The code slowly matured, with more models of the DECstation 5000 series becoming supported, and Rick Macklem contributed support for the Personal DECstation.
However, there was no native toolchain for BSD on MIPS; it relied upon the Ultrix cc, as and ld binaries running in emulation.
In parallel, building on that MIPS support, Japanese hackers, led by Kazumasa Utashiro, were working on BSD support for the MIPS-based Sony NEWS workstations; this work got eventually commited to the CSRG source tree on march 1993 as a news3400 port.
Here is what sys/news3400/README had to say:
# @(#)README 8.1 (Berkeley) 06/10/93
------------------------------------------------------------------------------
This Sony MIPS R3000 based workstation support is done as an activity of
WIDE research project. Sony Corporation contributed most device drivers
and gave us great technical supports. Kazumasa Utashiro worked mainly
4.4BSD implementation but that work was based on 4.3BSD-Reno port helped by
other project members, especially Tadamichi Matsuyama and Hidetoshi Unno.
This version is just a snapshot of developing system and has many
unimplemented features and bugs. Please contact utashiro@sra.co.jp if you
have any comments about this code. Bugfix will be greatly appreciated.
------------------------------------------------------------------------------
I've been using NWS-3200 laptop machine and NWS-3400 for development.
3200's LCD display and NWB-253 display board are supported now.
------------------------------------------------------------------------------
Currently GCC is used as a compiler which uses as and ld come with NEWS-OS.
They should soon be replaced by the latest GAS because it supports BSD
a.out format for MIPS.
------------------------------------------------------------------------------
Known bugs:
- Display driver is slow.
- Serial line driver is slow.
- Console doesn't accept ^S.
- Some problem probably in VM.
------------------------------------------------------------------------------
Kazumasa Utashiro
Software Research Associates, Inc.
1-1-1 Hirakawa-cho, Chiyoda-ku, Tokyo 102, Japan
and
WIDE Project
On the 16th june of 1993, Kirk McKusick commited a ``final update from Ralph'', and not much happened on the MIPS front until Ralph Campbell put ``final changes for pmax 4.4-Lite II release'' in early june 1995.
In the meantime, the NetBSD project had been created in 1993, with the goal of running on as many hardware platforms as possible. A port-pmax dedicated mailinglist was created in november 1993, and among the first messages on this list, Theo de Raadt, one of the founders of the NetBSD project and still involved in NetBSD at that time, wrote that he would "love a mips port".
From: Theo de Raadt To: port-pmax Subject: Re: General status information Date: 11/22/1993 19:15:44 > What's the status of the port? I've got a few spare DS2100 or better > class machines sitting around... The code is in the tree almost unchanged from how it was donated. It needs to be fixed to do things "the NetBSD way". A few people volunteered to help get this code working, but we've not heard much from them. The code is from 4.4 -- hence it is much easier/better to merge it into the NetBSD magnum branch. This branch is (as yet) not available to the net at large... only people who have sun-lamp accounts can work on it easily. The magnum branch does various things as they are done in 4.4. These things ARE important -- it would probably take 4-6 times longer to make the pmax code work in a NetBSD-current environment. A number of ports already use the magnum tree (sparc, sun3) and others are being changed to use it (i386, pc532). Yes.. that means there are about 4 people familiar with what changes need to be made. So, if you're a wiley hacker who wants to make this happen, get in touch with me. (It should not take too long if you pay close attention to what had to be changed to make the sparc port fit in, perhaps 2 weeks till you are able to build a crash-and-burn kernel.) I would *love* to see this port working.
However, a lot of work was required to make the port self-hosting, which was a strong requirement for NetBSD. Not much development happened behind the scenes, and the mailinglist was quite quiet, leading to Ralph Campbell himself (no longer at the University of Utah) asking for a status update early in may 1994.
This led to an answer from Adam Glass (another NetBSD co-founder) giving an optimistic timeline.
By the middle of june, the port had made significant progress.
Work progressed in order to get a native toolchain (based on gcc 2.5.8 and heavily modified binutils 2.4 at that time), but by the time NetBSD 1.0 was released, on november 8th, pmax was not yet an official part of the release.
Then Per Fogelström (not the swedish author!) appeared out of nowhere, with an EPIC message, revealing that he was in fact no less than the Chuck Norris of the MIPS world.
From: Per Fogelström
To: port-pmax
Subject: NetBSD Mips port, Success story.
Date: 12/10/1994 18:22:05
Hi everybody!
There have been much talk about the pmax port during the last days.
I'm not a pmax owner, have no funds, so i built my own system.
Porting NetBSD to it was quite stright forward so i don't recognize
all the problems you describe. Perhaps many of them arise from using
Ultrix as a porting plattform. :-> Or at least, using Ultrix C compiler
and tools is giving you problems.
Anyway i have a R3000 system running native without major problems.
This is the story how it was done. Maybe it can give you some ideas
or at least entertain you for a couple of minutes.
HOW NetBSD WAS PORTED TO NEW HARDWARE
=====================================
Building hardware is fun, but soner or later you come to the point where
you need software to do something meaningful.
So i started to look around. At work we had the BSD4.4 tapes and it included
a pmax port which was a good starting point. However BSD4.4 contain a few
licenced modules. To make this story short, NetBSD solved the issue.
A toolchain was needed to compile the code for my hardware and GNU was the
natural choise. Then i needed a porting plattform. So i had to dig the dungeon.
In my basement i had an old 68020 SYSVR3 un*x system which would do.
Next step was to create a cross development environment on the 68k system.
This was fairly easy, GCC runs on almost any system you might have.
I was now able to compile a NetBSD kernel from the pmax sources. After having
set up the include file hireachy the compile went through smoothly. Of course
i had no possibility to verify that it really worked. But as a starting point
for the rest of the work it could be considered as a milestone.
Then the time had come to start modifying and rewriting drivers for my own
system. I also had to create a bootstrap prom. Downloading and test took a
while because the only way i could download was via the serial port. Well,
after a few iterations (146 according to the version counter) the kernel was
working. At least until it tried mount the root disk.
Now the 'fun' part starts. Because i had no access to a BSD system i couldn't
create a file system on the hard disk. So i had to do it 'native'. The way
to do this was to hack "newfs" to run standalone with the bootprom hard disk
driver. Newfs was also hacked to create inodes for '/dev/console', '/dev/rz0a'
and "/dev/tz0". From this point i had a system which paniced because there
was no init process.
Next step was to create the rest of the system software. The tiresome process
of compiling all neccesary librarys was started. The libs was then installed
in the cross development system. It was now possible to cross compile the rest
of the system and create a distribution file system tree. Now how to download
the file system tree on the NetBSD disk? The file tree was "tared" out on a
streamer tape and i now had a 'system tape'. The problem to solve now was how
to get the tape down on the disk.
To load the tape to the NetBSD disk i needed a tar program that i could run
on the target system. To do this the kernel was hacked. The first hack was to
make the kernel mount the root disk r/w, open '/dev/tz0', copy the tape to a
file in the root directory, syncing the disks and then halt. What was there on
the tape then? Some of you might have guessed; a hacked :-) tar program. This
tar mounted the root disk, opened '/dev/console' and then started with options
'xvf /dev/tz0'. The kernel was hacked again to started this program instead
of init and downloaded. The 'distribution' tar tape was loaded, the hacked
kernel started and.... ta da da da, the tape was loaded to the hard disk.
Next step, reeboot with the downloaded kernel and viola, the system asked
for the shell to run!! I entered 'sh' and the '#' prompt showed up on the
terminal. Hurray!! It works, well almost. A few more things had to be fixed
in locore.s and the terminal driver.
From this point the rest of the system was crosscompiled and the last thing
crosscompiled was the complete GNU toolchain. Next step was to recreate the
whole system native and the when this was done, the plug was pulled on the
old 68k system.
Of course it requiered a number of tries before the download succeded. But
what was most amazing was that the system programs, sh, init, almost all of
the just worked! My only misstake was that the system i built was big-endian.
To all of you who made it to here, hope you enjoyed the reading.
I would really like to help you guys to get NetBSD for the MIPS boxes
housebroken. Most of my spare time right now is spent on porting it to
a R4400 board i got recently. The kernel will of course be different but
the rest of the system would pretty much be the same as for the pmax.
One suggestion that i have, based on my own experience, is that someone
creates a pmax/Ultrix GCC environment that people who compiles kernels
can use and put it up for ftp. You can then stop using Ultrix tools.
I will not take up more of your time right now, but if anyone has some
ideas let me know if and how i can be of any help.
Regards
Per
You can imagine all the list subscribers with their mouths wide open in awe. I know I was when I first read that mail.
(Three days later, Jonathan Stone and Theo de Raadt had their first clash over a technical discussion about MIPS write buffers. This would end up with Theo de Raadt expelled from the NetBSD project a few months later.)
In the meantime, Per Fogelström kept working on the R4400-based board he had been referring to in his epic mail: an Acer PICA.
When the OpenBSD project started for real in october 1995, Theo de Raadt, who had also been able to get an Acer PICA, convinced Fogelström to share his code with him, and that became the OpenBSD/pica port.
The PICA was a machine compatible with the ARC (Advanced Risc Computing) specification, but there were a dozen or so ARC-compatible machines, manufactured by DeskStation, MIPS, Olivetti and NEC, among others.
It made thus sense to support these compatible machines under a more representative name, and in late august 1996, the OpenBSD/pica port was superseded by a new version of its codebase, known as the OpenBSD/arc port.
ARC-compatible MIPS systems were available for a few years and then, after Microsoft announced Windows NT 4.0 would be the last version to support this platform, disappeared completely. As a Unix workstations collector, one of my (many) frustrations is that I have never seen any ARC machine on the second-hand market in Europe. I really would like to eventually find one, but it looks like these machines either suffer from electronic failures, or their owner does not want to part with them, something I understand very well.
As summarized by Theo de Raadt some time in 2004 when GXemul (still called mips64emul at that time) grew ARC support and this was shortly discussed in the OpenBSD private chat:
<deraadt> dead junk hardware. i had 3 in a row, and each of the boards died.
Meanwhile, at SGI, there were a few Linux-enthusiasts who thought that it would be nice to see Linux run on the low-end systems of the moment, especially the Indy; and given how Indy and Indigo2 were close to each other, there was hope of running on the Indigo2 as well eventually.
That group was led by Ariel Faigon, who first got a mailinglist created to discuss that idea, and second, with the help of Larry McVoy who was working at SGI at that time, convinced Dave Miller of linux-sparc fame to spend a three-months internship at SGI to work on a Linux port.
(That mailinglist, initially hosted at SGI as linux@engr.sgi.com, would move some years later and become the linux-mips mailing list, no longer affiliated to any vendor in particular. The loss of the entire linux-mips site and content due to a hardware failure a few years ago has been a tragic loss; thankfully, some of its contents are still available on the Wayback Machine.)
Few people remember this, but Dave Miller was also an OpenBSD developer during the first few months of the project, where he was working both on OpenBSD and Linux sparc ports. Once Linux did run reliably enough on sparc, he stopped contributing to OpenBSD, his last OpenBSD commit being on the 14th of january 1996.
To: linux list at sgi Subject: He he he Date: Fri, 15 Mar 1996 20:45:18 -0800 From: Larry McVoy I like news like this. By the way, we are really really close to signing David as a summer intern here. He's certainl'y a handful (the only person that I know that swears more than I do, and if you've hung out in B9, you know that's saying a lot :-) We're working on ways to channel all that energy and I think we have a plan. As soon as it is official, I'll post the details here. I think Ariel wants to have a Linux on SGI kickoff meeting soon - I hope folks are hip to that. ------- Forwarded Message Date: Fri, 15 Mar 1996 21:52:22 -0500 From: David S. Miller To: Larry McVoy Subject: The Ultra 176MHZ I'm not impressed with it's performance at all. Ho hum... maybe that will change when I get Linux running on it, perhaps Solaris is the problem here. Later, David S. Miller ------- End of Forwarded Message
Subject: Linux/MIPS port resources To: linux list at sgi Date: Fri, 19 Apr 1996 11:47:45 -0700 (PDT) I was thinking about what should we do to make David Miller come up to speed as fast as possible when he comes for the summer. After all, he may not be familiar with MIPS assembly, IRIX etc. So I set up a *preliminary* Web page with a list of resources for the Linux/MIPS port. Most of the pointers are from Bill Earl, thanks Bill. Please send me suggestions for improvement, what's missing, etc. This is just a quick first shot so you get the idea. The 6.2 freeware gcc is not yet configured to work with GNU-as (so it uses stabs and supports debugging) and our linker. I'll be working on this next week. We also need to make sure that all the equipment, the office, etc. is ready when David lands here. I assume someone is taking care of all this (?). And that someone with intimate knowledge of our low level stuff is really available to assist him on call. I'll leave it to Larry or Greg to announce the details on David Miller's accepting SGI's offer. p l e a s e :-) 6 weeks to go... -- Peace, Ariel
Date: Fri, 19 Apr 1996 14:52:28 -0700
From: Larry McVoy
To: linux list at sgi
Subject: Good news
Hi-
as some of you know, we've been negociating to get David Miller,
the Sparc/Linux guy, to come out and work on a MIPS/Linux port. He has
accepted, he starts on May 25th, and will be here until August 25th.
We had to do a lot of work with the laywers, but we have agreement that
all of the work that he does here will be
a) owned by SGI (we paid for it), and b) distributed under the
terms of the GPL.
No exceptions. SGI owns the code so we can choose to use anything that
turns out to be interesting inside IRIX without the constraints of the
GPL (you may or may not be aware that the owner of the code can choose
to distribute the code under multiple copyrights - so we can use stuff
in IRIX without "polluting" the IRIX kernel with the GPL).
I'd like to thank everyone that has been pulling for this, and especially
Greg Chesson who did the hard work of getting the contract hammered out
to the satisfaction of SGI & David.
We are currently in the process of figuring out what code we can use to
help with the port; there may be parts of the setup OS that are both
appropriate and useful.
Ariel and others are working to get a development machine set up in
the engr domain. It will be linux.engr.sgi.com, and should be up and
running on Monday or Tuesday.
I'll keep you posted on new news as it happens.
--lm
---
Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804
Copyright 1996, all rights reserved. Microsoft Network is prohibited from
redistributing this work in any form, in whole or in part without license.
License to distribute this work is available to Microsoft at $500.
Transmission without permission constitutes an agreement to these terms.
I also still enjoy that particular mail:
Date: Mon, 22 Apr 1996 21:40:01 -0400
From: David S. Miller
To: Ariel Faigon
CC: linux list at sgi
Subject: Re: David Miller is on the list
From: Ariel Faigon
Date: Mon, 22 Apr 1996 18:16:30 -0700 (PDT)
Great, now you can tell the list what do you need :-)
Oh boy.
Seriously, we've been thinking about how we could make you most
productive and not waste your time when you arrive here.
Here's a recent posting of mine, so you get the idea just in case
Simon or Bob or Larry didn't tell you about all this yet...
Feel free to bombard us with requests/questions.
There are about 20 people on the linux list at SGI
(you can query majordomo@engr.sgi.com for the details)
Already did that an hour ago ;)
(note: I looked back over this mail after composing it and I want to
warn people who are not familiar with me yet that I am very
sarcastic and am full of ridicule even when discussing
important topics. Please don't take it that I lack tact
or am not being serious, because that simply isn't the case.)
Here is what I need:
The following utilities I need for development.
1) CVS/RCS, latest on prep.ai.mit.edu is fine
2) Emacs-19.31 (rms should release within 2 weeks)
3) All GNU smidgen-type utilies as the default binaries
(this include fileutils/sh-utils/sharutils/diffutils/
findutils/...)
Actually, Let me just stop short and say, if there is a
source tarball for it on prep.ai.mit.edu:/pub/gnu I would
like the latest installed on the machine I develop on.
4) xfishtank (don't laugh)
5) fvwm
6) teco (Must support full teco command set as described
in original DEC manuals! TECO is _the_ renaissance editor!)
The following would be nice, but if it will give people
bladder problems to do these then don't go out of your
way:
1) MIPS 4[40]00 manual is some online format (not postscript,
something I can cut and paste out of an emacs buffer etc.
so maybe info or pure ascii text would be fine, I could
care less about the formatting, I just want the words
there)
2) Docs on the ethernet/scsi interfaces and I/O bus
architecture for the first machine I will be getting
this to work on, again text/info format would be nice.
Of course I will probably just stuff in the ready
drivers you might be getting to me into Linux but I want
to write my own from scratch in the near future after
that.
3) I know as much as a bum on the street about SGI machines
and the various lines, a nice "roadmap to sgi workstations
and servers, plus the hardware gook thats inside" type
thing would be very useful to me.
I will feel more comfortable if:
1) I became very familiar with who the heavy low level MIPS
assembly level hackers are who I will be dealing with while
I am there. Please tell me who they are, introduce, make
us say hello to each other, you get the idea.
2) I know the policy on loud music in the office I'll be in
;-)
I've thought it over and to me the best plan for things this summer to
me is:
a) R4400 32-bit "proof of concept, yeah we can pull it off"
port happens first, side effect is that I become intimate
enough with the chip that I can do things more efficiently.
b) From here we look into the 64-bit stuff and whether that is
is even desirable on 64-bit. (this would be my first
64-bit port outside of my initial UltraSparc hacks)
c) Also think about the work needed to turn that code into
r3000 friendly code. Should not be too much as I've done
the "write it on recent architecture design then backport
it to older design which had some limitations" already and
this didn't end up being so bad.
Expect more as I think it up... this should keep you guys busy for
now.
(Any dead-head tape traders at SGI engineering? Just wondering, may
want to start talking to them now ;-)
Later,
David S. Miller
By the end of his intership, Linux was running on the Indy, with Ethernet and SCSI support, and, if I remember correctly, some minimal glass console support in addition to a working serial console. Ralf Bächle spent some time after that to merge Dave Miller's tree into the current linux-mips tree, as his porting effort had been based off a different Linux kernel version (2.0.14, while the current linux-mips kernel was 2.1.21). Bringing in the sgi-specific parts, which were new, was the easy task, while merging the useful fixes he had made to the common MIPS code required more attention.
Note: there will be several status tables across the years. The IPxx notation below corresponds to a given hardware design, with IP standing for Inhouse Processor, to differentiate them from the very first SGI workstations (Iris 1000) which were based upon a licensed third-party design similar to the Sun-1; as you will see later in this narration, these IP values appear often in developer communication as a way to precisely identify a given piece of hardware. Plus it's shorter, written that way!
| SGI model | common name | Linux |
| IP24 | Indy | kernel no bootloader no distribution XL (newport) graphics only no X server |
Ariel Faigon had hoped that Dave Miller would return to SGI for another internship the next year, Miller had other plans and did not resume working on SGI support for Linux. This task was taken over by Mike Shaver and Miguel de Icaza, in addition to Ralf Bächle. With the help of Alex de Vries, who would later initiate the PA-RISC porting effort, they eventually managed to build a variant of the RedHat Linux distribution for the Indy, called HardHat.
Among all the MIPS hardware he had collected, Per Fogelström had an SGI Indy machine. These systems use a firmware interface which is close to ARC, with minor differences. It was reasonable to expect the existing OpenBSD/arc code to work on this machine, with only minor changes.
And indeed, it did. Near the end of august 1997, Per Fogelström had the beginning of a port, running diskless with a newport frame buffer console, and rough edges which would disappear once people would spend enough time fixing them.
(That codebase also hardcoded the Ethernet address of the onboard interface to 08:00:69:08:9c:54; if you ever encounter an Indy machine with that Ethernet address, you'll know that it used be Per's and that it is a small part of OpenBSD history.)
Yet, for reasons unknown to me, this work was not commited to the OpenBSD tree. In february 1998, Michael Shalayeff got access to a few SGI O2 systems which were no longer in use at his dayjob, and asked Fogelström for information about this hardware, but Fogelström didn't know much about the O2. Shalayeff nevertheless asked him to share his work-in-progress OpenBSD/sgi code with him, something Fogelström eventually did in march. Despite keeping telling that he would commit that code soon, still nothing happened. Then Shalayeff got busy with his own PA-RISC porting work and gave up on SGI, or at least didn't find time to tinker with it anymore.
(It was really frustrating for me to discover this many years later, as I strongly believe that, if there had been a visible effort to make OpenBSD run on the Indy in 1997, there would probably have been much more interest, and more other SGI systems would have been supported earlier.)
| SGI model | common name | Linux | OpenBSD |
| IP22 | Indigo2 | kernel no bootloader XL (newport) graphics only no X server |
|
| IP24 | Indy | kernel no bootloader XL (newport) graphics only no X server |
kernel no bootloader diskless XL (newport) graphics only no X server not public |
(Follow this link to go forward to the next part.)