The collected works of skylark

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
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
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
Not surprised it's slow on Indy, the hw accel on Indy is practically nonexistant. I'm writing a Really Nice (tm) MIPS disassembler Very Soon Now (I plan to start working on it at July 6) and look exactly into how does one initialize the MGRAS card (I already figured out how to load microcode, and the HQ4 ucode loads fine, but verification of the GE11 ucode hangs the card rock solid, so I guess I missed some configuration detail earlier on).

When the card is initialized, limited OpenGL (no context switching) is extremely simple, as OpenGL calls map directly to register writes (thanks, SGI!). Context switching is, on the other hand, very hard.
objdump -d will not automatically, for instance, decode calls to printf() and display what is actually printed, as this kind of data flow analysis is not implemented. Neither it is easy to do in a Perl script. The same about gp-relative indexing. I want to identify high-level structures, like while() loops and if()s, too.

Stanislaw
Heh, yes! I'll be working on SMP shortly. I must say that Octanes are the most beautifully engineered machines I have ever seen. SGI, they were good :)

And I learnt somewhat more about IRIX internals, too. Writing a debugger that can trace Xsgi while it's running was... interesting :)
Well, I managed to find out how to DMA images to and from the graphics. It was not easy because there are several workarounds involved (e.g. you can't DMA from the gfx in the vertical flip mode, you've got to switch it, DMA, and switch it back).

About the linux-mips: most of the traffic is now on #mipslinux IRC :)