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
