Miscellaneous Operating Systems/Hardware

While looking through the gentoo "Other Architectures" forum, i came across a post which stated that some guy in Poland had got linux drivers working for Impact Series of GFX.
Did some digging about on linux-mips and found the following two screenshots of linux booting on a Octane
http://helios.et.put.poznan.pl/~sskowron/ip30/ip30-linux-con.jpg
http://helios.et.put.poznan.pl/~sskowron/ip30/ip30-linux.jpg

I better don my asbestos suit to protect myself from Cosmos

...May be we'll be knowing about Linux-MIPS driver-coding advances, after all!
Many times better than a PlayStation2 tuxed box, if you need Linux and even think on MIPS, I think!

I see a kernel panic. That's not booting. ;-P

Anyway. Cool stuf. No matter what peeps say, it would be cool to have a dual-booting Octane :-D

Indeed, the issue with the kernel panic is they are having problems with the qlogic scsi controller. Or he was back with his 2.6.1 patch. If you look in his download directory he has a patch for 2.6.5.

some interesting reading in it. Like the fact that the Octane can technically support 4proceesors but as no quad module was released, the function wasn't used.

+ Actually, the HEART supports up to four processors on the SysAD bus. It is
+only because of unavailability of four-processor modules that the Octane can't
+take an advantage of this.

http://helios.et.put.poznan.pl/~sskowron/ip30/linux-2.6.5-ip30.patch.bz2

kumba on gentoo forums wrote: He does in fact, and since my last post, he's got s kernel that will boot more, and if you have an NFS Root lying around, you can get a semi-usable userland. Things like the keyboard driver are still not implemented yet, same goes for the scsi subsystem (meaning if you try to do anything, even installing linux, it will be over NFS Root). All can be found here:

http://helios.et.put.poznan.pl/~sskowron/ip30/


--Kumba

this is good even if cosmos hates it, it means we can get some documentation on the hardware at last.

for example, who read this thread and got the evil idea of building a quad-cpu module or a sub-pcb to link a couple of twin modules together?
i did!

Intel-OUTSIDE wrote: this is good even if cosmos hates it, it means we can get some documentation on the hardware at last.

for example, who read this thread and got the evil idea of building a quad-cpu module or a sub-pcb to link a couple of twin modules together?
i did!

It seems that he tried to get an NDA with sgi regarding Octane documentation but they wouldn't have any of it (typical)

As for a quad module, sounds like a job for Chicago-joe to me.

Intel-OUTSIDE wrote: this is good even if cosmos hates it, it means we can get some documentation on the hardware at last.

for example, who read this thread and got the evil idea of building a quad-cpu module or a sub-pcb to link a couple of twin modules together?
i did!

...mmmhhhh... that's sounding like a clear call for a mission from the "Chicago-Joe" agent!

Yes, the project is a cool thing, besides the Cosmos hating; more interesting even if anyone could add a work about the O2 platform too...

Intel-OUTSIDE wrote: this is good even if cosmos hates it, it means we can get some documentation on the hardware at last.

You get no documentation for the Octane hardware. It's all wild guessing. I'll never use an operating system that'd guess what to write in any hardware registers. It is not the right way to make a port.

Intel-OUTSIDE wrote: for example, who read this thread and got the evil idea of building a quad-cpu module or a sub-pcb to link a couple of twin modules together?
i did!

No way with Octane RACER. Period.


On the asbestos - I'd suggest a good lead shielding as I prefer neutron sources :).

Diego wrote: Yes, the project is a cool thing, besides the Cosmos hating; more interesting even if anyone could add a work about the O2 platform too...

Linux boots on R5K O2's from what i remember, there's supposedly some issue with R10K's one though. I just had a look at the netbsd page and they say they support both R5k and R10k O2's
http://netbsd.org/Ports/sgimips/

Dubhthach wrote:

Diego wrote: Yes, the project is a cool thing, besides the Cosmos hating; more interesting even if anyone could add a work about the O2 platform too...

Linux boots on R5K O2's from what i remember, there's supposedly some issue with R10K's one though. I just had a look at the netbsd page and they say they support both R5k and R10k O2's
http://netbsd.org/Ports/sgimips/

Oh yeah. I see. I was in this page a few times. But I'm meaning "Full Support" (i.e.: framebuffer, ethernet, ICE module, MVP...)

...well, ok!, if a good only-framebuffer support is there I'll take it!

I cand put one O2 only to testing purposes....

Diego wrote:

Dubhthach wrote:

Diego wrote: Yes, the project is a cool thing, besides the Cosmos hating; more interesting even if anyone could add a work about the O2 platform too... :)

Linux boots on R5K O2's from what i remember, there's supposedly some issue with R10K's one though. I just had a look at the netbsd page and they say they support both R5k and R10k O2's
http://netbsd.org/Ports/sgimips/

Oh yeah. I see. I was in this page a few times. But I'm meaning "Full Support" (i.e.: framebuffer, ethernet, ICE module, MVP...)

...well, ok!, if a good only-framebuffer support is there I'll take it! ;)

I cand put one O2 only to testing purposes....

Hrmm, should watch this forum more often...

Anyways, O2 support in Linux is what I'd call in the semi-functional stage. Nothing near the support of Linux on an indy, but it's functional enough. Here's a quick run-down of what is and isn't supported in O2/Linux:

Supported:

• SCSI (in PIO mode, MMIO is still buggy last I checked)
• R5000 (RM5200 Untested, but should work, given Cobalt systems use the same exact CPU model)
• Meth ethernet
• Serial Ports, PS/2, Parallel (I've never tested it personally, but in theory...)

Semi-supported (i.e., experimental ...)

• GBE Framebuffer (I think works if configured for 2MB, But unsure. O2 can run X for remote X sessions, however, I've seen a guy run GNOME on it under Linux via a remote session)
• PCI Slot (mostly works I think, but still has glitches, and not every PCI card will work (i.e., PCI Vid Cards)

Unsupported:

• VICE module
• RM7000 (Issues with ternary cache, I believe)
• R10000/R12000 (Issues regarding speculative execution; requires a workaround which is currently being explored)
• Add-on modules (Dual-head, maybe, I'll be getting one in soon, so I can test it. Flat Panel display, unknown, possibly not, but really unsure).
• Booting off the harddrive. Booting from the Volume Header is doing something funky inside the machine, and arcboot, a IP22 bootloader (originally) made by a debian guy needs some more hammering with a large blunt object before working properly. Thus, only Netboot works, and only when the O2 wants it to work. My experience has shown that depending on the toolchain used (gcc/binutils), the time of day, kernel options, and alignment of the stars all play a role in determining if the O2 PROM will netboot a linux kernel or not. Once it boots though, the machine is rather stable, able to do silly things like survive gcc/glibc compiles rather easily.

Overall, very nice machines. my O2 running Gentoo definitely smokes my Indigo2, Indy(s), and RaQ2 also running Gentoo, and provided I can ever get my hands on an RM5200 for really cheap prices on eBay, I can maybe get it to run even faster. Atleast until R10K/R12K is semi usable, then I'll have to hunt one of those models down. If you're willing to suffer with serial console, O2's run rather stable.

And for reference :)



--Kumba

Kumba wrote:
Semi-supported (i.e., experimental ...)[list][*]GBE Framebuffer (I think works if configured for 2MB, But unsure. O2 can run X for remote X sessions, however, I've seen a guy run GNOME on it under Linux via a remote session)

Sure Kumba!; seems to me very interesting even: enoughly to try the first framebuffer-fully-functional version of the distribution.

It's not an offense, I'm not telling that the support for the O2 devices is a bad thing.
But I'm just programming heavy duty graphics engines, and I'm interested to see what can do these nices O2 babies with a fully 64-bit supported operating system.

Just curious!

You get no documentation for the Octane hardware. It's all wild guessing. I'll never use an operating system that'd guess what to write in any hardware registers. It is not the right way to make a port.

Very funny. But, you know, reading kernel disassembly is not guessing. It just requires lots, and lots, and lots, and lots of accuracy. Some people just can sit for 16 hours straight trying to guess what these 8 kbytes of code actually do.

Sorry, I infer you never wrote an OS kernel - or you are simply ignoring your experience. Can you, for instance, imagine that in the last month, when I was porting Linux to some obscure SH-3 subplatform I found several bugs in the docs (MMU-related)? Do you know what happens if you step on one of them? Yeah, that's right: you are guessing ! There is no such thing as a 'perfect documentation'. It's a dream we hackers can share, but the reality is quite different.

If you have the IRIX sources, scan them for 'WAR' or 'workaround'. You will see all the places in which the documentation was inaccurate (usually due to a hardware bug). Each of these places, I'm sure, is a memorial of some poor hapless engineer getting stuck with his work and trying to make sense of something that could not happen, i.e. guessing .

Back to the Octane.

Sometimes it is guessing, but I'm always trying to check in the IRIX kernel or the PROM for anything similar to what I intend to do, and try to match these patterns. It's more effective than simply reading the code, as it's more targeted. Besides, sometimes I get workarounds for free (several of them).

Anyway, in fact only the HEART and MGRAS are really unique to the Octane. HEART is a simple device (programming-wise), you can use it as a transparent memory and XIO bridge in ways that are well-documented in the headers. IRQs are a little harder, but still nothing special.

On the other hand, MGRAS is incredibly complex. The driver for it is however 100% workable (the public version is a little less stable, as I have found some code in the disassembly that gives me FIFO level checking, and I haven't integrated them into the publicly available patches yet). I have based it on the PROM code.

The rest of chips are mostly supported by Origin drivers, and - as you may well know - these drivers are based on Ralf's work at SGI. Yes, he had access to docs.

Interesting sidenote: the, reportedly supported by qLogic (with full documentation), qlogicisp drivers crash on the Octane. No, it's not a bug in PCI. It's simply different firmware. So, was the documentation really that useful, huh?

I intend to write a much better disassembler in the following two months so the work will go faster and there will be less space for human error here, too.

for example, who read this thread and got the evil idea of building a quad-cpu module or a sub-pcb to link a couple of twin modules together?
i did!

No way with Octane RACER. Period.

Of course, no way. I would not try it. Writing kernel is easy. Designing hardware is hard. Believe me, I'm doing both.

Donning asbestos _and_ lead shielding (note: lead inside asbestos). And going to my subterranean vault, too.

Stanislaw Skowronek

welcome to nekochan skylark, hopefully you'll find it a useful resource, not all of us IRIX people bite

Hello, and thanks for your warm welcome!

IRIX was my first Unix experience... Not Linux, not Solaris, just a room full of Indigos. I really liked it, and I like it still (although sometimes it is too slow).

What I don't like is the fact that I can't easily hack around the hardware (not even the PCI bus), which is what I really like doing.

Stanislaw

What sorta hardware you got in your development Octane, all i can tell from the net is it's a single proc box running MGRAS graphics.

This will be (sorry if partnos are inaccurate, I'm quoting from memory):
* one IP30 system board (030-1487-005)
* 1GB of SDRAM (eight modules, full house)
* one PM10 1x250MHz, 1MB cache processor module (030-1284-002)
* one ESSI graphics
This is about it when it comes to options. The rest is standard (no PCI cage, no TRAMs, nothing).

Stanislaw

It's damn slow on an Indy (i don't remember specs of the Indy though). Don't bother to try. Together with someone else i ported GNUstep to Linux/MIPS just for fun. Also very slow, ofcourse. APT was horribly slow for example. Seems the same rule which applies on old Sun hardware (run SunOS on it, not GNUBSD) also applies on old SGI hardware.

A real benchmark is more interesting than just the feelings imo.

One of the most interesting usages (ie. Challenge S as firewall) is not possible because GIO64 is not supported, hence no Phobos.

Here's info to get Linux running on O2/R10000
http://www.linux-mips.org/~glaurung/
It's also possible to boot Linux over the network on O2/R10000.
I know someone who has this working succesfully (but not a native installation! -- yet)

O2 used to be working on NetBSD, went broken, but works again. NetBSD supports the following

* IP12 machines
o Indigo (R3000)
o 4D/30, 4D/35 (theoretical/untested)
* IP20 machines
o Indigo (R4x00)
* IP22 machines
o Indigo2 (R4400)
o Challenge S
* IP24 machines
o Indy (R4400, R4600, R5000)
* IP32 machines
o O2 (R5000, RM5200, R10000, R12000)

http://www.netbsd.org/Ports/sgimips/

Would be interesting to see one of those overclocked O2's running on ie. O2. If anyone has done this, and has information on performance, please share.

Orakel wrote: One of the most interesting usages (ie. Challenge S as firewall) is not possible because GIO64 is not supported, hence no Phobos.

For the record, Challenge S uses GIO32bis, not GIO64. The Mezzanine board is indeed not supported (yet).
Challenge M uses GIO64, BTW.