(Follow this link to go back to the main SGI page, and this link to go back to the previous part.)
Linux started to get working Origin 200 support in january. It took a few months to work stably, and multiprocessor support only landed in april, and wasn't stable until june.
That code was heavily relying upon knowledge gathered from IRIX header files, to the point some mistakes were made when "creating" Linux header files.
Date: Mon, 15 May 2000 19:38:28 +0000
From: Ralf Baechle
To: linux-cvs@oss.sgi.com
Subject: CVS Update@oss.sgi.com: linux
CVSROOT: /home/pub/cvs
Module name: linux
Changes by: ralf@oss.sgi.com 00/05/15 12:38:28
Modified files:
include/asm-mips64/sn: intr.h intr_public.h nmi.h
Log message:
Fix copyright message. Linus flamed me on these messages so please
make sure for the future that the (C) notice is ok. ``unpublished
proprietary information of Silicon Graphics'' isn't good ...
There was not much communication about that support, however, apart from an article on the popular (back then) news site slashdot, which I couldn't find anywhere in its archives anymore.
In the spring of 2000, NetBSD developer Soren Jorvang started to work on a port to the SGI O2, using information from the IRIX system headers as the only documentation, and the existing NetBSD MIPS codebase as a solid fundation.
His work was first commited to the NetBSD tree on june 14th, with a first complete NetBSD snapshot available on the 29th. However, possibly due to bugs in the generic MIPS code in NetBSD, this code was not running as stably as expected, and one of the first hurried fixes was to disable the second-level cache of the R5000-family processors (R10000-family O2 were not supported yet.)
The O2 platform is a non-coherent architecture, when it comes to its cache memory behaviour.
This means that there are no electronics in charge of making sure that every device in the machine sees the same memory contents, at any time. This matters for devices able to perform Direct Memory Access, such as most I/O controllers (on the O2, the SCSI controller, the Ethernet controller, the Audio/Video board, etc.)
Non-coherent systems are frequently encountered in legacy workstations (and even to this day in small computing devices, such as Raspberry Pi or StarFive boards), and all operating systems running on such hardware will perform explicit cache flushes and/or invalidations, in order to make sure that no cache has, even partial, contents of the memory which is about to be modified by a DMA transfer.
But some O2 add extra difficulty to that problem: the R10000 processor.
The R10000 processor performs speculative execution in order to have better performance: when a branch point is reached, it tries to follow both "branch taken" and "branch not taken" instruction flows, so that, at the time it is known whether the branch is taken or not, it is not slowed down. Of course, the other half of the work, for the wrong outcome of the branch, gets discarded.
In an ideal world, discarding the wrong set of instructions would be completely transparent. But it is not - there are subtle, minor side-effects of the speculative execution which can't be undone (well, they could, but that would require a lot more machinery in the processor, and it was deemed acceptable to let these side-effects exist.)
This side effect is that, if a load instruction is speculatively processed, the processor will perform the memory load. If the data is not found in cache, this will cause it to be fetched from memory, and put in cache. If a store instruction is speculatively processed, the same thing may happen, with the cache line being marked as dirty (modified), so that it will get written back to memory when it needs to be evicted from the cache.
So if a speculative store is processed using a memory address which will be written to by a DMA operation, there is a risk that the processor's view of the memory area will be wrong, and there is also a risk that the processor will write back outdated data from its cache to that area.
In order to prevent these unwanted side effects, some processor instructions can act as speculation barriers, blocking further speculative execution until the instruction completes; and there are also several code generation tricks, documented in the R10000 processor manual, to reduce the risk of unwanted side effects.
Speculative execution has no ill effects when the processor is running userland code, because accesses to addresses which would cause a MMU fault (because the access would be made to an address which computation would involve a register value, and the register value is nonsensical in the stream of instructions which will be discarded, for example.) But the kernel has access to the complete physical memory through the XKPHYS area of the 64-bit virtual address space, and these addresses do not need to be translated by the MMU.
Because of this feature, the risk of speculative execution causing these side effects was considered nonzero by the O2 designers, and they implemented an extra defense against them in IRIX:
The sad situation of the O2 support did not prevent people from tinkering with the idea of running NetBSD on their SGI machine, even if it was not an O2.
In late april, Rafal K. Boni had his Indigo2 run multiuser.
Subject: Indigo2 boots to multiuser!
To: port-sgimips
From: Rafal Boni
Date: 04/27/2001 10:51:43
Folks:
I've gotten my Indigo2 booting well enough that it gets to multi-
user mode, and seems to be able to run most things fairly well.
I haven't tried anything like building a source tree yet, but
we'll get there at some point.
There's still loads of work to be done (notice we have no RTC
driver, hence the box things it's at the start of the unix
epoch, there is no SCSI driver so this is all over NFS, the
ZS driver isn't in good enough shape to boot single-user yet
so this is using the ARCS console...) but thought this was
exciting enough to send out some mail.
[...]
His work was commited to the NetBSD source tree by Jason Thorpe on may 11th.
Although the O2 support was still in bad shape, this was an important milestone as it allowed the SGI-specific code to be better split into generic "a machine running a MIPS processor on SGI's variant of the ARCBіos firmware" code, and per-particular-model code.
An SCSI controller driver for the Indy and Indigo2 was added in august by the late Wayne Knowles, who significantly improved it in november.
The last important code piece, a standalone bootloader, allowing the NetBSD kernel to be booted from disk instead of accross the network, was pieced by Michael Hitch in november 2001.
There had been patches floating around to let Linux run on the O2 systems, after NetBSD showed the way. But none of them would be seriously crafted, often breaking support for Indy while adding O2 support, because the people working on O2 support did not necessarily also have an Indy or Indigo2 machine, or were not being careful enough making their changes.
This changed in december 2001 when Vivien Chappelier, then a student at the École Nationale Supérieure des Télécommunications in France, started to spend quality time with his O2, and submitted patches which were not always correct, yet were of a much higher quality than previous efforts. This allowed him to receive valuable feedback, improve his code, and get his patches eventually accepted to the linux-mips tree.
| SGI model | common name | Linux | NetBSD | OpenBSD |
| IP22 | Indigo2 | kernel no bootloader XL (newport) graphics only |
complete distribution no graphics |
|
| IP24 | Indy | kernel no bootloader XL (newport) graphics only |
complete distribution no graphics |
|
| IP27 | Origin 200, Origin 2000 | kernel no bootloader |
||
| IP32 | O2 | not-yet-integrated kernel patches no R10000 support no bootloader no onboard Ethernet no graphics |
complete distribution no R10000 support no graphics no onboard Ethernet kernel does not run stably |
Vivien Chappelier did not remain inactive, and contributed support for the O2 on-board Ethernet interface in july, and a frame buffer driver in december.
Late november, the Origin 200 and Origin 2000 code, which had be rotting and was no longer in working condition, got repaired and improved by Ralf Bächle, restoring proper support for these systems.
O2 support was reported as ``very broken'' at the beginning of the year.
Subject: Re: O2 doesn't boot To: port-sgimips From: Christopher SEKIYA Date: 01/03/2002 20:35:30 On Thu, Jan 03, 2002 at 06:11:23PM +0900, Toru Nishimura wrote: > It should not be a hard job to tailour NetBSD/sgimips for RM5200, I think. O2 support is very broken: * The walk-the-ARC-tree-for-cache-detection code does not work properly, * watchdog is turned on too early, breaking console settings slower than 38400, * PCI code handles memory space mapping but not IO space mapping, breaking most ethernet cards, * interrupt masks are incorrect, * interrupt handler is very spooky and frequently deadlocks the machine. There's more that's wrong, but that's an executive overview. Adding the proper logic for a 5200 won't result in a working machine. I've fixed #2 and mostly fixed #4 and #5 from the above list, have worked around #1 and found a card that will mitigate #3, but my O2 will still fall over three times out of five once interrupts are turned on. Is anyone else working on fixing the O2 support? I'll send what I have to interested parties. -- Chris
However, by the very end of the year, Christopher Sekiya had reached a state where his O2 was running stably again.
From: Christopher SEKIYA To: port-sgimips Subject: New IP32 kernel/patchset Date: 12/29/2002 11:04:03 Ladies and gentlemen, I've put diffs against today's -current and a test kernel for the IP32 at http://www.rezrov.net/software/netbsd/ip32-diff-20021229 and http://www.rezrov.net/software/netbsd/netbsd-ip32-20021228, respectively. Apart from cosmetic changes to facilitate repository commits, the following changes have been made since Rafal's last snapshot: * the timer is properly calibrated. The system should no longer consistently lose time. * ahc is recognized as a boot device. * the crime interrupt handler more closely resembles a "real" interrupt handler. In conjunction with boot.ip32, I've succeeded in booting my IP32 from disk straight to multiuser. The system appears to be stable. Share and enjoy, -- Chris
After almost three years of inactivity, Per Fogelström found time and motivation to resume working on the OpenBSD codebase, firstly for his own company (Opsycon AB) and its PMON2000 extensible firmware product. With the availability of embedded boards with high-end MIPS chips, there was an interest for a 64-bit MIPS version of PMON2000... and also for a 64-bit MIPS version of OpenBSD.
But 64-bit MIPS support in the GNU toolchain (gcc and binutils) was still in its early beginnings, with many 64-bit specific bugs in gcc (while 32-bit MIPS code generation was quite reliable) and 64-bit MIPS ELF targets in binutils were new and not well-tested yet.
Over the last week of february 2002, on the private OpenBSD developer chatroom, he mentioned his current progress multiple times.
<pefo> well, i'm trying to move the mips kernel to 64 bit, not with full 64 bit
addressing yet, but run into issues here and there.
[...]
<pefo> hi
<pefo> what version of binutils is in the tree right now?
<pefo> 2.10.1
<pefo> is this what is going to be in [OpenBSD] 3.1 or will an upgrade be done
before that?
<pefo> mips have problems in 2.10 and needs 2.11 thats why i'm wondering.
[...]
<pefo> morning
<pefo> what a dull day...
<pefo> <lebel> hmmm. 5.3 hours for a make build under an Ultra 2, at 400MHz.
<pefo> takes 4,4 hours on a 400Mhz mips machine. go get sgi's a port is coming!
:-)
And here we go, the idea of an OpenBSD/sgi port is coming back.
The day after:
<pefo> my 64bit mips kernel is now starting to run init. looks good so far but
still things that needs to be fixed.
<pefo> looking forward to that O2.
And the next day:
<pefo> heh, OpenBSD/mips64 now have shell prompt! :-)
<niklas> sweet
<niklas> and mips32? :-)
<pefo> don't tell theo but it runs in o32 emul mode. :-)
<pefo> mips32 per se is already working fine. i'm trying to keep the kernel code
as generic as possible so if someone insist on making an OpenBSD/mips32
it should work. more or less a matter of compilation options.
<pefo> now i can't think of any reason why to make a mips32 kernel unless
someone wants to start fighting old R3000 hw again... no don't look at me.
<pefo> a mips64 kernel is only about 10% larger than a mips32 kernel.
Two weeks later:
<pefo> nice to have some good progress now and then. mips64 is starting to work
really well. still much work but it looks really good so far.
<wcobb> pefo, do you plan on merging mips anytime soon?
<pefo> as soon as i have all 64 bit pieces going. actually theo says he want it
clean and fixed before importing it. there are a few issues regarding
endianness etc that has to be dealt with.
<wcobb> i'd be glad to help
<pefo> i'm currently playing with gcc 3.0.4 and binutils 2.12 which seems to
work pretty well so far.
<pefo> i know.
<wcobb> binutils 2.11 cannot handle mips64, right?
<pefo> 2.11 has a lot of problems. 2.11.94 which is close to 2.12 handles o32,
o64 but not yet n32 and 64.
<pefo> 2.11 can do o64. i've been compiling the kernel with that until now. that
is the 64 bit kernel.
<wcobb> i've never got even o64 working with 2.11 here.
<wcobb> the IP30 prom can only load a 64bit kernel, IP32 seems more flexible.
<pefo> "<wcobb> the IP30 prom can only load a 64bit kernel" do you by that mean
it can only load ELF64?
<wcobb> yes
<pefo> i see, thats a different thing. 2.11 will not do that. it will only work
ok when doing ELF32 files.
<pefo> what kind of SGI machines do you have?
<wcobb> Indy, Challenge S, Indigo2, O2 and single-CPU Octane
<pefo> cool, looks like you are going to get busy! :-)
<wcobb> that is, if i can get my hands on your code =)
<wcobb> i'm curious to see how you're handling caches
<pefo> well, caches seems to be one of the hardest things to grasp...
<wcobb> L2 caches are a pain
<pefo> well, as long as one remembers to deal wit orphans it's no problem.
<pefo> then if you define a set of cache operations coupled to the action
instead of encapsulating the various cache commands in functions it's
really easy to deal with it. but people always aproach the problem from
the wrong direction.
<pefo> then not understanding the behaviour of non-snooping caches and think
that busdma will be the universal solution is a *big* mistake...
<pefo> put these things together with some aliasing, and voila! you have
stability problems.
One week later, a short status update:
<pefo> well, i have a working (to some extent) kernel and have made a simple o32
emulation to allow the older o32 binaries to run. not everything will
work but i wanted something to help me bootstrap the 64 bit world. a
couple of strange things happen which i need to track down to either
compiler/toolchain problems or my code.
<deraadt> how many boxes do you run on?
<deraadt> anything common for our developers to get?
<pefo> three. haven't started sgi yet. wcobb is hot on it though :-)
<pefo> have an O2 standing beside me that i'm going to play with soon
<deraadt> Good.
<deraadt> there are small fast sgi machines, right?
<pefo> have spent quite some time on getting the tools to do the right thing and
have 80% of 64 bit userland built -static. shared stuff later if o64 hold
water.
<pefo> all new code i create under mips64 is supposed to work in ISA2-ISA4 mode,
eg both 32 and 64 bit mode. but i'm not going to do anything with ISA1,
eg R3000 now. it's to painful...
A few bugfixes later, at the end of march, our hopes of getting a 64-bit sgi port were high.
<pefo> the SGI porting work will really take off now. i have an Indy, and an
Octane on its way here from US.
<pefo> what is the SGI machine status around here, what do we got? Indigo2 i
know, what else? yeah, i have an O2 also.
Two weeks later in april, the same optimistism:
<pefo> morning. the probability for [OpenBSD] 3.2 to have a SGI port is becoming
higher and higher.
<deraadt> good. what hardware is working?
<pefo> o2 is my first target. will attack that hard next week.
<deraadt> if it is getting close, pefo, it is going to become time for you to
hook a few developers up with the right hardware soon. like miod, me,
and a willing ports person, probably one of brad (toronto) or naddy
(germany). so that we can do our end of the cleaning
<pefo> wcobb is looking at the octane.
<pefo> i will go back to the indy after i have the o2 going.
<deraadt> well you will need to ensure we get hardware
<deraadt> and please, small hardware? :-)
<deraadt> small + fast + cheap (the latter is not as important)
<pefo> so if things work ok at least indy, o2 and octane will be supported as a
start.
<deraadt> great.
<pefo> you can get an indy for $100
<millert> SGI hardware is relatively cheap these days.
<deraadt> what is the fastest PC-size sgi?
<millert> I have no idea
<pefo> the o2 with a R12000. still rather expensive. you can the a 200Mhz R5K o2
for about $250-500. sometimes they go really cheap on ebay.
<deraadt> and how fast is it
<millert> Yeah, I would think a cheap octane would be the way to go
<pefo> octanes is hard to get under $500-600.
<millert> But that is not too expensive
<deraadt> well, for the first few, we will just have to ask.
<pefo> fast is relative. but if we look at tree build performance an r5k/200
will probably build the tree in 6-7 hrs. now it feels that gcc 3.x is
becoming even slower though...
<deraadt> well, that isn't too horrible.
<deraadt> we do not have any middle of the line machines at the moment
<deraadt> < 3 hour and > 20 hours.
<pefo> if get the O2 port up and running it is possible that we can get a few
donated from where i got some of the extra stuff for the octane i bought.
And then there were no further signs of life from Per...
Late may:
<pval> what's up with the sgi stuff? <pval> haven't seen pefo here in a while <deraadt> Who knows.
Fogelström appeared again in december, with an important question.
Date: Mon, 30 Dec 2002 17:58:30 -0800 From: Per Fogelström To: private OpenBSD mailinglist Subject: SGI system type poll Hi, I've now started to code the SGIMIPS kernel and thought i should check what type of systems you guys have. My first target will be the O2 since that is what i have around and what i consider reasonable. The box that sits here is a R5000 so that will be what is going to work first. The other box i have is a R10000 but it's on loan right now but if there is people with O2 R10K's it will be the next target. I have also started to search for O2 frambuffer info and if anyone have any i would appreciate that. Since the O2 is a shared memory buffer design it would probably be fairly easy to get a dumb framebuffer X port working when the details are uncovered. Once the kernel is operational i think there is little work left to have almost everything working. I currently have 1600+ packages compiled although not everything is tested! :-) At least KDE and some other stuff is working fine on my Galileo/Marvell Discovery system as i'm typing this using KMail... So stay tuned! :-) Per
There were not many reactions. I said I was more interested in Indy and Indigo2 support at the moment since these were the systems I had, but wouldn't mind if other systems were supported first. It looked like the general attitude was "wait and see".
| SGI model | common name | Linux | NetBSD | OpenBSD |
| IP22 | Indigo2 | kernel no bootloader XL (newport) graphics only |
complete distribution no X server |
|
| IP24 | Indy | kernel no bootloader XL (newport) graphics only |
complete distribution no X server |
|
| IP27 | Origin 200, Origin 2000 | kernel no bootloader |
||
| IP32 | O2 | not-yet-integrated kernel patches no R10000 support no bootloader |
complete distribution no R10000 support no graphics no onboard Ethernet kernel does not run stably |
likely some private tinkering no R10000 support status unknown |
Not much happened for Linux on SGI that year.
Guido Guenther wrote a standalone boot loader, arcboot, allowing Indy and O2 to finally boot Linux from disk.
In a message to the linux-mips mailing list in november, Ralf Bächle acknowledged that Linux on the O2 was not really ready for end-users.
Date: Wed, 12 Nov 2003 14:53:33 +0100 From: Ralf Baechle To: BETTLER Emmanuel Cc: linux-mips Subject: Re: O2 and Linux boot problem [...] Linux for O2 is still in it's very early stages, don't expect much success with it for the moment. Hackers welcome :) Ralf
On the older side of the SGI hardware spectrum, Steve Rumble made NetBSD run on the R3000-based Indigo (IP12, the first generation of Indigo systems) in april and shared his work-in-progress code, which would however not get commited until one year later.
On the more modern side of the spectrum, there was not much visible progress this year, until the last quarter of the year, where O2 support was repaired in october thanks to the efforts of Christopher Sekiya, and R10000 processor support was added shortly afterwards.
On december 15th, glass console for Indy systems with the ``newport'' (XL) frame buffers was added.
And to end the year on a good note, Christopher Sekiya added support for the R4000-based Indigo (IP20, the second generation of Indigo systems) on december 31st.
Fogelström came back early january, to complain about the state of OpenBSD's driver for the Adaptec AIC-7880 SCSI controller found onboard the SGI O2, which code was not endian-neutral at that time.
<pefo> aic7xxx.c is severly broken. i found a lot of BE issues. swapping of
already swapped adresses, faulty busdma_syncs... looks like i have a lot
of work to do here... :(
<pefo> NetBSD don't use our code. it's not based on the same FreeBSD version
even.
<pefo> ahc0: PCI error Interrupt at seqaddr = 0x7f <-- from OpenBSD on SGI O2.
<pefo> not much choice. i need to get this driver working.
<deraadt> ahc? why ahc?
<pefo> aic7880 <- builtin on the O2. two of them. the free pci slot is needed
for an ethernet board until the builtin ethernet is figured out.
<deraadt> wow. what is the builtin ethernet?
<pefo> something 'homemade'. sits in a big asic.
<deraadt> seeq?
<mickey> hmm, i think it's thunderlan (at least that what i had on my r5k)
<deraadt> sgi owns seeq, if i recall.
<pefo> that could be found out while looking at the published .h files.
<pefo> have to go. cinema time.
<pefo> btw, whoever wants to play with ethernet is welcome! :)
<mickey> well i do not have mine anyymore
<mickey> (;
<pefo> at least the kernel is coming alive. another week or so i would guess...
It only took one day of work for the situation to improve, as reported on the next day:
<pefo> sd0 at scsibus0 targ 1 lun 0: <SGI, IBM DCAS-32160W, S68A> SCSI2 0/direct fixed :) <pefo> from the O2 <henning> heh, cool! <henning> so you have ahc BE clean now? <drahn> If you do, I would like to see those diffs. <jason> Whoa, BE clean ahc? That would ROCK. <pefo> yes, it was (so far) two places of swaps and one missing dmasync. <drahn> gimme <henning> wonder if that could help with some of the general ahc probs... <jason> not on i386... no dmasync's necessary on that arch. <pefo> dmasync, no. dmasync and BE will help sparcs with PCI though.
And one day later:
<pefo> showtime:
<pefo> > boot -f bootp():bsd.sgi
<pefo> Setting $netaddr to 192.168.16.70 (from server mammoth)
<pefo> Obtaining bsd.sgi from server mammoth
<pefo> 2140912+246880 entry: 0x80100080
<pefo> Copyright (c) 1982, 1986, 1989, 1991, 1993
<pefo> The Regents of the University of California. All rights reserved.
<pefo> Copyright (c) 1995-2002 OpenBSD. All rights reserved. http://www.OpenBSD.org
<pefo> OpenBSD 3.2-current (GENERIC) #97: Thu Jan 9 04:21:38 CET 2003
<pefo> pefo@mammoth:/archive/OpenBSD/3.2/src/sys/arch/sgimips/compile/GENERIC
<pefo> real mem = 67108864
<pefo> avail mem = 58425344
<pefo> using 819 buffers containing 3354624 bytes of memory
<pefo> mainbus0 (root)
<pefo> cpu0 at mainbus0: MIPS R5000 CPU Rev. 2.1 with MIPS R5000 based FPC Rev. 1.0
<pefo> L1 Cache: I size 32kb(32 line), D size 32kb(32 line), two way.
<pefo> macebus0 at mainbus0
<pefo> macepcibr0 at macebus0: chip revision 1, host system O2.
<pefo> pci0 at macepcibr0 bus 0
<pefo> ahc0 at pci0 dev 1 function 0 vendor 0x9004 product 0x8078 rev 0x00: irq 1
<pefo> ahc0: aic7880: Wide Channel A, SCSI Id=0, 16/255 SCBs
<pefo> scsibus0 at ahc0: 16 targets
<pefo> sd0 at scsibus0 targ 1 lun 0: <SGI, IBM DCAS-32160W, S68A> SCSI2 0/direct fixed
<pefo> sd0: 2049MB, 8188 cyl, 3 head, 170 sec, 512 bytes/sec, 4197405 sec total
<pefo> cd0 at scsibus0 targ 4 lun 0: <TOSHIBA, CD-ROM XM-6401TA, 1003> SCSI2 5/cdrom removable
<pefo> ahc1 at pci0 dev 2 function 0 vendor 0x9004 product 0x8078 rev 0x00: irq 2
<pefo> ahc1: aic7880: Wide Channel A, SCSI Id=0, 16/255 SCBs
<pefo> scsibus1 at ahc1: 16 targets
<pefo> fxp0 at pci0 dev 3 function 0 vendor 0x8086 product 0x1229 rev 0x08: irq 4, address 00:90:27:a5:47:58
<pefo> inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
<pefo> com0 at macebus0: ns16550a, 16 byte fifo
<pefo> com0: console
<pefo> com1 at macebus0: ns16550a, 16 byte fifo
<pefo> boot device: lookup 'unknown' failed.
<pefo> root device :
<pval> sweet =P
<pefo> next thing is fixing the interrupts and i think this little toaster will
run :)
<mickey> the oxygen toaster ?
<pefo> yup
<philipp> oh
<mickey> hmm, it has fxp onboard, i bet i had thunderlan
<pefo> no, it's in the pci slot. the onboard ethernet is still unknown...
<mickey> ah it's not on pci ?
<pefo> the fxp is a quickstart solution until the built in ethernet is working
<pefo> no, it's not on pci. it's in the same asic as the pci bridge but not a
generic pci device.
There are a few interestings things to observe in the above boot sequence:
And of course, Fogelström disappeared again, until early september:
[=Sign-on=] pefo (pefo@[XXX.XXX.XX.XX]) entered group
<deraadt> holy shit, a swedish developer
<deraadt> we've not seen a swedish developer in weeks
<pefo> yeah...
<miod> hello pefo
<pefo> hi miod
<miod> probably because it's their 6 month night now
<deraadt> so is sgi ever going to happen?
<todd> hi pefo
<pefo> summer have ended and we are crawling back to our caves ;-)
<pefo> hi todd
<todd> I've been bugging pefo to get his sgi's back online. rumor has it one is ..
<pefo> OK, a mips machine is available for remote access for those who wants to
hack mips code. It runs 3.3 right now and have my mips/sgi sources on
line.
<deraadt> do you want to incorporate things into the tree after unlock?
<pefo> sgi/O2 stuff can probably go in. i'm rearranging the tree per your
request first. the only thing i want to do before going public with
things is to move over to n32/n64 abis as default.
<deraadt> n32/n64?
<miod> err, isn't n32/n64 the abi horribly poorly supported by binutils?
<miod> afaik they have decent o32 code, but nothing for n32
<deraadt> do you mean i32lp64?
<deraadt> i do not know this other notation
<pefo> the new ABIs. Have better call methods (faster), uses 8 arg regs instead
of 4 and have less overhead.
<deraadt> oh, it is an abi, is it on top of i32lp64?
<pefo> not any longer.
<pefo> yes. n32 is i32 n64 is lp64
<miod> i'd say no because I only consider 32bit systems here (-:
<miod> pefo, you mean you have written n32/n64 code for binutils?
<pefo> no, not me but redhat.
<miod> oh. I was not aware of this.
<miod> that's excellent news.
<pefo> i have the code and i think it is in the cvs now also. there are some
specific tweaks for the RM9000 which i'm not sure about but that doesn't
matter yet.
<Nick> this is still the newer SGI stuff, my Indigo2 is still SOL, right?
<miod> nick, you can enjoy netbsd and serial console only on it (-:
<miod> and no L2 cache (unless they fixed this recently)
<Nick> oh, and those two wonderful, SGI-only 20" monitors. *sigh*
<pefo> Indigo2 may come later. We have to start somewhere and O2 is a good
place. It's a decent machine both in speed availability and price.
[...]
<deraadt> pefo, you got propolice working?
<deraadt> too bad mips is totally incapable of W^X
<pefo> yes, its no news. The R10K is a little "special". There may be a couple
of rare RM52xx and RM7000 around as well. Those are OK.
<miod> i'd expect pp to misbehave on mips, if only because mips cpus smell bugs.
Even though they're a dream to program for, from an userland pov...
<miod> but then i also expected it to misbehave on m88k and it did not.
<pefo> Yes i'm running 3.3 with stack protector on. no problems seen so far.
<deraadt> pefo, contact etoh to see if he wants to do any tests
<pefo> make build goes thru with no problems.
<pefo> ok
The interesting part of this conversation is the discussion about the ABIs. At that time, there had been already four levels of instruction sets for MIPS processors, each level being a superset of the previous one.
Since OpenBSD/sgi was to be a 64-bit port, it would target MIPS3 and MIPS4 processors only - from the R4000 up.
In the early MIPS days, when it was still a 32-bit processor, the original ABI for MIPS code allowed for up to 4 function call arguments to be passed in registers, any further argument being passed on the stack. MIPS processors having 32 general-purpose registers, this was a horrible mistake, and having allowed more registers for parameter passing would have been better, but it was too late to fix that. But when 64-bit support was introduced, MIPS engineers seized the opportunity to fix that, and designed a better calling convention for 64-bit code, using up to 8 registers for parameter passing.
This new calling convention was called n64 (n for new), and in retrospect, the old 32-bit calling convention was called o32 (o for old). Then, users of 32-bit code realized it would be a good idea to also use 8 registers for parameter passing, and their adaptation of n64 to 32-bit code was called n32. Then, because "why not", gcc added an o64 calling convention, which is the equivalent of o32 for 64-bit code, and noone sane should use it unless forced to.
For the OpenBSD port, it was clear n64 was the way to go, but this required reliable code from binutils and gcc, and whether this code was reliable was yet to be discovered.
| SGI model | common name | Linux | NetBSD | OpenBSD |
| IP12 | Indigo (R3000) | complete distribution no graphics |
||
| IP20 | Indigo (R4000) | complete distribution no graphics |
||
| IP22 | Indigo2 | complete distribution XL (newport) graphics only |
complete distribution no graphics |
|
| IP24 | Indy | complete distribution XL (newport) graphics only |
complete distribution XL (newport) graphics only, no X server |
|
| IP27 | Origin 200, Origin 2000 | complete distribution | ||
| IP32 | O2 | not-yet-integrated kernel patches no R10000 support |
complete distribution no graphics no onboard Ethernet |
kernel no bootloader no R10000 support no graphics no onboard Ethernet not public yet |
In april, Stanislaw Skowronek appeared on the linux-mips list with the first bits of Octane support.
Date: Mon, 12 Apr 2004 22:51:13 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips Subject: Work on IP30 My Octane got as far as 'Calibrating delay loop... ' now. It works with ARCS graphical console, which is a Good Thing. Memory identification is correct. Caches work OK. I'm going to do the IRQs tomorrow, but I foresee it will be really hard as there is no documentation for the HEART. Well, we shall experiment. Fortunately, the Octane has one really nice feature: the power button is hooked up to an interrupt source. It may prove quite useful for debugging. Interesting note: the ARCS console breaks when I change KSEG0 cache coherence in the CP0_CONFIG register (in c-r4k.c). Of course, it breaks sooner or later, not exactly afterwards, unless I flush cache exactly after changing; it breaks immediately then. I don't give a hoot, because IP30 has almost no RAM in KSEG0 and the kernel runs in XKPHYS, always cached copy-on-write. But those of you with another machines might be interested. Stanislaw Skowronek
A few days later, he had made progress:
Date: Fri, 16 Apr 2004 23:13:29 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips Subject: IP30 goes relatively far now Hello, I'm currently doing a reverse-engineered IP30 port of Linux-MIPS. Currently I'm using 2.6.1 as my base. I don't know if it's been already fixed in >2.6.1, but in genex.S there should be a 'nop' between 'jal do_\handler' and 'ret_from_exception'. The symptom is a hang on 'Checking for the daddi bug...'. Somebody apparently got used to '.set reorder' :P Well, now the kernel crashes a bit later. Actually, it gets to 'mice: PS/2 mouse device common for all mice' and then gets an Instruction bus error. I will look into this. Currently the kernel supports only MGRAS graphics (SI, SSI, MXI, SE, SSE, MXE) and uniprocessor. I don't have a SMP machine here, but I guess it would not be particularly hard to do. The ODYSSEY (VPro) would be a bit harder, as its architecture is vastly different from the MGRAS. Anyone interested may send me a VPro6 ;) When I get to 'cannot mount root', I will release the kernel patch. Yours, Stanislaw Skowronek
On the 25th, as promised, he shared his code.
Date: Sun, 25 Apr 2004 19:18:16 +0200 (MET DST)
From: Stanislaw Skowronek
To: linux-mips
Subject: Work on IP30
Hello!
I have placed a alpha version of my patch for Octane at:
http://www.et.put.poznan.pl/~sskowron/ip30/
Things currently unsupported:
* SMP will not work,
* qLogic SCSI driver oopses at the start,
* keyboard is not written yet,
* VPro (Odyssey) graphics,
* ARCS console,
* serial console,
* PCI card cage (trivial, but I can't test it as I don't have one)
Things not yet tested:
* new Octanes and Octane2s,
* user mode (yes! I don't have yet a MIPS glibc to cross-compile for
user mode),
* almost everything
Stanislaw Skowronek
The next month, he was able to run userland, albeit diskless, as there were still problems with the SCSI driver.
Date: Mon, 10 May 2004 22:54:03 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips Subject: Octane - first light! Well, we've got usermode now. There is no keyboard driver so I can't comment on interactive work (and I am too lazy to set up a complete telnet server :), but all interesting scripts I gave it worked. Network is OK, the QLogic SCSI driver does not work for some reason or another (it can't communicate with hardware - why?), the console driver is nice and seems to work rock-solid, high IRQ load (ping -f) does not break anything. I found another 32-bit infelicity in kernel/scall64-o32.S in stackargs: using subu instead of dsubu for jump address calculation... Any more of these and I will have an overflow exception on anger. Tomorrow, or somewhere in the next week I'm doing keyboard support. Stanislaw Skowronek
Another good surprise was due in may, as Peter Fürst posted a promising boot on a POWER Indigo2 R10000 (IP28):
Date: Sat, 15 May 2004 08:36:35 +0200 (CEST)
From: Peter Fuerst
To: linux-mips
Subject: IP28
How many Linux logins took place on a IP28-machine before ... ?
with kind regards
peter fürst
[...]
Starting up the system...
To perform system maintenance instead, press
System Maintenance Menu
1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor
Option? 5
Command Monitor. Type "exit" to return to the menu.
>> unsetenv OsLoadPartition
>> setenv OsLoadOptions "root=/dev/nfs nfsroot=192.168.1.1:/var/V/mipseb ip=192.168.1.28:::255.255.255.0::eth0:"
>> printenv
SystemPartition=bootp():
OSLoader=vmlinux
OSLoadFilename=vmlinux
AutoLoad=Yes
TimeZone=PST8PDT
console=d1
diskless=0
dbaud=9600
volume=80
sgilogo=y
autopower=y
netaddr=192.168.1.28
eaddr=08:00:69:0b:11:e2
boottune=0
ConsoleOut=serial(0)
ConsoleIn=serial(0)
cpufreq=174
OSLoadOptions=root=/dev/nfs nfsroot=192.168.1.1:/var/V/mipseb ip=192.168.1.28:::255.255.255.0::eth0:
>> boot
Setting $netaddr to 192.168.1.28 (from server Opal.Peter)
Obtaining /vmlinux from server Opal.Peter
2053216+397312+155512 entry: 0xa800000020200000
init_arch(7,9000000020ffe300,9000000020ffdf70,a800000020200000),
CP0: status 34004880, cause 0000801c, config 6c11ac03 ...
ARCH: SGI-IP28
PROMLIB: ARC firmware Version 64 Revision 0
CPU revision is: 00000925
FPU revision is: 00000900
load_mmu: R1X000 (20) ...
Primary instruction cache 32kB, physically tagged, 2-way, linesize 64 bytes.
Primary data cache 32kB 2-way, linesize 32 bytes.
Unified secondary cache 1024kB 2-way, linesize 128 bytes.
init_arch: start_kernel() ...
Linux version 2.4.22 (pf@Opal.Peter) (gcc version 2.95.4 20010319 (prerelease)) #163 Sat May 15 02:22:59 CEST 2004
Entering setup_arch()...
MC: SGI memory controller Revision 5
MC: Boardrev. 0, Chiprev. 13
MC: Probing memory configuration:
bank0: 64M @ 28000000
bank1: 64M @ 2c000000
bank2: 128M @ 20000000
Determined physical RAM map:
memory: 0000000010000000 @ 0000000020000000 (usable)
On node 0 totalpages: 196608
zone(0): 196608 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Leaving setup_arch().
Kernel command line: root=/dev/nfs nfsroot=192.168.1.1:/var/V/mipseb ip=192.168.1.28:::255.255.255.0::eth0:
Calibrating system timer... 875000 [175.0000 MHz CPU]
Using 87.500 MHz high precision timer.
Console: colour dummy device 80x25
zs0: console input
Console: ttyS0 (Zilog8530), 9600 baud
Calibrating delay loop... 174.48 BogoMIPS
Memory: 242616k/262144k available (2005k kernel code, 19528k reserved, 260k data, 100k init)
Dentry cache hash table entries: 131072 (order: 9, 2097152 bytes)
Inode cache hash table entries: 65536 (order: 8, 1048576 bytes)
Mount cache hash table entries: 256 (order: 0, 4096 bytes)
Buffer cache hash table entries: 65536 (order: 7, 524288 bytes)
Page-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking for 'wait' instruction... unavailable.
Checking for the multiply/shift bug... no.
Checking for the daddi bug... no.
Checking for the daddiu bug... no.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
pty: 256 Unix98 ptys configured
DS1286 Real Time Clock Driver v1.0
SGI Zilog8530 serial driver version 1.00
tty00 at 0xbfbd9830 (irq = 45) is a Zilog8530
tty01 at 0xbfbd9838 (irq = 45) is a Zilog8530
Hardware Watchdog Timer for SGI IP22: 0.2
sgiseeq.c: David S. Miller (dm@engr.sgi.com)
eth0: SGI Seeq8003 08:00:69:0b:11:e2
SCSI subsystem driver Revision: 1.00
wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00
setup_args=,,,,,,,,,
Version 1.25 - 09/Jul/1997, Compiled May 13 2004 at 20:54:51
wd33c93-1: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00
setup_args=,,,,,,,,,
Version 1.25 - 09/Jul/1997, Compiled May 13 2004 at 20:54:51
scsi0 : SGI WD93
scsi1 : SGI WD93
sending SDTR 0103013f0csync_xfer=2c
Vendor: FUJITSU Model: M2954S-512 Rev: 0142
Type: Direct-Access ANSI SCSI revision: 02
sending SDTR -REJ-
Vendor: TOSHIBA Model: CD-ROM XM-5401TA Rev: 0436
Type: CD-ROM ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
SCSI device sda: 8498506 512-byte hdwr sectors (4351 MB)
Partition check:
sda: sda1 sda2 sda3 sda4
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.12
SGI HAL2 revision 0.1.0
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 4096 buckets, 64Kbytes
TCP: Hash tables configured (established 131072 bind 65536)
IP-Config: Complete:
device=eth0, addr=192.168.1.28, mask=255.255.255.0, gw=255.255.255.255,
host=192.168.1.28, domain=, nis-domain=(none),
bootserver=255.255.255.255, rootserver=192.168.1.1, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.1.1
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 100k freed
do_execve(/sbin/init)...
INIT: version 2.74 booting
[...]
Hard Hat Linux Hard Hat release 5.1 (Copenhagen)
Kernel 2.4.22 on a mips64
indigo2 login:
[...]
He spent the next months cleaning his code, and published a first version of his patches in august.
Date: Sat, 21 Aug 2004 02:17:40 +0200 (CEST) From: Peter Fuerst To: linux-mips Subject: IP28 Kernel patches Hello ! The Kernel patches for SGI Indigo2 R10k (IP28) can now be found at http://home.alphastar.de/fuerst/download.html with kind regards...
Hardware support made progress in NetBSD too in 2004.
First, Steve Rumble's code for the original (R3000) Indigo (IP12) got merged by Antti Kantee.
Date: 04/11/2004 16:28:32
From: Antti Kantee
To: port-sgimips
Subject: IP12 support in-tree
I've just finished pushing Steve Rumble's IP12 (4D/30, 4D/35, Indigo
R3k) code into -current (hopefully the changes will make it also into
NetBSD 2.0). Machines should be able to boot to multiuser at least using
a NFS root now (sd0 root untested, probably some funnies hiding there).
Things seem to work mostly okay, the only big issue is with nfs root
going berzerk if you try to use the default fragment sizes. Steve hinted
that using small read and write fragment sizes might do the trick,
and at least it's a working workaround for me:
dm:/m/dm/nfs/4lom / nfs rw,-w=1024,-r=1024 0 0
A kernel config file is not yet available due to changes that are going to
(hopefully!) happen before NetBSD 2.0. But for the millions of people
out there who can't just wait to run NetBSD on their IP12's, it's pretty
easy to mop GENERIC32_IP2x into a good IP12 kernel conf:
* change TEXTADDR from 0x88069000 to 0x80002000
* replace MIPS3 with MIPS1 (yes, replace, needs investigation)
* add: pic0 at mainbus0 addr 0x1fa00000
* add: gio0 at pic0
Thanks go naturally to Steve Rumble for writing most of the code and an
endless stream of answers to questions about SGI hardware, and also to
Chris Sekiya for shipping me a battery to replace the dead one on my IP12
(.. and answering questions.. and working on abstracting sgimips enough
for support to be easily dropped in.. and ..).
Enjoy! Obligatory bootlog follows.
>> hinv
Memory size: 32 Mbytes
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
System option: Audio processor, revision 3
CPU board: IP12 33 MHz, with FPU
System option: Audio processor, revision 3
>> boot
Setting $netaddr to 10.181.181.183 (from server dm)
Obtaining netbsd from server dm
1434800+0+170476 entry: 0x80069000
argv[0]: bootp()netbsd
[ Kernel symbol table missing! ]
Mem block 1: type 0, base 0x0000, size 0x0001
Mem block 2: type 2, base 0x0001, size 0x0fff
Mem block 3: type 2, base 0x1000, size 0x0800
Mem block 4: type 2, base 0x1800, size 0x0800
Mem block 5: type 4, base 0xfc00, size 0x0000
Loading cluster 1 (before kernel): 0x1 / 0x68
Loading cluster 1 (after kernel): 0x1f1 / 0x1000
Loading cluster 2: 0x1000 / 0x1800
Loading cluster 3: 0x1800 / 0x2000
zs channel 0 had address 0xbfb80d10
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 2.0C (4LOM) #367: Sun Apr 11 15:15:22 EEST 2004
pooka@brain-damage.localhost.fi:/sys/arch/sgimips/compile/obj/4LOM
total memory = 32768 KB
(0 reserved for ARCS)
avail memory = 30308 KB
mainbus0 (root): SGI-IP12 [SGI, IP12], 1 processor
cpu0 at mainbus0: MIPS R3000A CPU (0x230) Rev. 3.0 with MIPS R3010 FPC Rev. 4.0
cpu0: 32KB/4B direct-mapped Instruction cache, 64 TLB entries
cpu0: 32KB/4B direct-mapped write-through Data cache
int0 at mainbus0 addr 0x1fb801c0
pic0 at mainbus0 addr 0x1fa00000
pic0: Revision B: dblk (0x2), iblk (0x8)
pic0: cache disabled, store partial, bus drive
gio0 at pic0
Synchronous ISDN (product 0x04 revision 0x00) at gio0 slot 2 addr 0x1f000000 not configured
hpc0 at gio0 addr 0x1fb80000: SGI HPC1
zsc0 at hpc0 offset 0xd10
zstty0 at zsc0 channel 1 (console i/o)
zstty1 at zsc0 channel 0
zsc1 at hpc0 offset 0xd00
zsc1: channel 1 not configured
zsc1: channel 0 not configured
int0: cannot share interrupts yet.
sq0 at hpc0 offset 0x100: SGI Seeq 8003
sq0: Ethernet address 08:00:69:06:2b:01
wdsc0 at hpc0 offset 0x11f: WD33C93A SCSI, rev=0, target 0
scsibus0 at wdsc0: 8 targets, 8 luns per target
dpclock0 at hpc0 offset 0xe00
biomask 0b netmask 0b ttymask 1b clockmask 7f
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 1 lun 0: <CONNER, CP3500-540MB-3.5, 3236> disk fixed
sd0: drive offline
sd0: sync (200.00ns offset 12), 8-bit (5.000MB/s) transfers
boot device: <unknown>
root device: sq0
dump device:
file system (default generic): nfs
root on sq0
nfs_boot: trying DHCP/BOOTP
nfs_boot: DHCP next-server: 10.181.181.1
nfs_boot: my_domain=localhost.fi
nfs_boot: my_addr=10.181.181.183
nfs_boot: my_mask=255.255.255.0
nfs_boot: gateway=10.181.181.1
root on dm:/m/dm/nfs/4lom
root time: 0x4079371b
readclock: 2004/4/11/12/16/9
time.tv_sec = 1081685769, time.tv_usec = 960000
init path (default /sbin/init):
init: copying out flags `-s' 3
init: copying out path `/sbin/init' 11
Enter pathname of shell or RETURN for /bin/sh:
Terminal type? [unknown]
Terminal type is unknown.
We recommend creating a non-root account and using su(1) for root access.
# Sun Apr 11 12:17:30 UTC 2004
Starting file system checks:
Setting tty flags.
Setting sysctl variables:
Starting network.
Hostname: 4LOM.localhost.fi
Configuring network interfaces: sq0.
add net default: gateway 10.181.181.1
Adding interface aliases:
Building databases...
Starting syslogd.
Checking for core dump...
savecore: /netbsd: kvm_openfiles: /netbsd: No such file or directory
Apr 11 12:18:00 4LOM savecore: /netbsd: kvm_openfiles: /netbsd: No such file or directory
Setting date via ntp.
setclock: 2004/4/11/12/18/24
Starting rpcbind.
Apr 11 12:18:25 4LOM rpcbind: cannot create socket for udp6
Apr 11 12:18:25 4LOM rpcbind: cannot create socket for tcp6
Mounting all filesystems...
Clearing /tmp.
Checking quotas: done.
Setting securelevel: kern.securelevel: 0 -> 1
Starting virecover.
Starting local daemons:.
Updating motd.
Starting sshd.
Starting inetd.
Starting cron.
Sun Apr 11 12:19:11 UTC 2004
NetBSD/sgimips (4LOM.localhost.fi) (console)
login:
[...]
A few months later, Christopher Sekiya added almost complete support for the XZ (Elan) graphics option.
Date: 07/09/2004 07:39:04 From: Christopher SEKIYA To: port-sgimips Subject: IP12/20 wscons support in-tree All, I've just committed the final bits for grtwo wsconsole support on the IP20 (and probably IP12 -- the hardware is the same). It should now be possible to use a monitor/keyboard as console. There is still more work to do -- there is no cursor, and column copy/erase is problematic; however, it seems quite useable. Enjoy, -- Chris
Unfortunately, his hardware would stop functioning shortly afterwards, and he never got to improve this code (which contains an infinite loop he probably was lucky enough not to trigger in his testing, which I fixed years later while completing the work on this frame buffer for OpenBSD.)
The next week, the much more awaited driver for the onboard Ethernet interface on the O2 was also commited by Izumi Tsutsui.
Subject: Re: On-board MACE MAC-110 Ethernet on O2 (on-going) From: Izumi Tsutsui To: port-sgimips Date: 07/11/2004 12:35:18 [...] > After a bunch of try and error, now the driver is mostly functional: > http://www.ceres.dti.ne.jp/~tsutsui/netbsd/if_mec-20040709.tar.gz I've committed the driver with some further enhancements (especially interrupt and cache handling). http://mail-index.netbsd.org/source-changes/2004/07/11/0001.html As noted the commit log message, this driver still needs more tests. If you find any problems, please report via send-pr(1).
And what about 2004 in OpenBSD? There is a lot to tell, so this will be in the next installment. Which is why there the "fall 2004 status" table below is intentionally incomplete.
| SGI model | common name | Linux | NetBSD |
| IP12 | Indigo (R3000) | complete distribution no graphics |
|
| IP20 | Indigo (R4000) | complete distribution no graphics |
|
| IP22 | Indigo2 | complete distribution XL (newport) graphics only |
complete distribution no graphics |
| IP24 | Indy | complete distribution XL (newport) graphics only |
complete distribution XL (newport) graphics only, no X server |
| IP27 | Origin 200, Origin 2000 | complete distribution | |
| IP28 | POWER Indigo2 R10000 | not-yet-integrated kernel patches otherwise same as IP22 |
|
| IP30 | Octane | not-yet-integrated kernel patches X server on Impact only |
|
| IP32 | O2 | not-yet-integrated kernel patches no R10000 support |
complete distribution no graphics |
(Follow this link to go forward to the next part.)