Help getting IP30/Octane fixed?

Well, I've been keeping the Octane/IP30 port alive for quite some time lately, but the bitrot in the code is making the functionality get progressively worse.
As of 2.6.30, the following will _not_ work:

- SMP capabilities (hangs on boot)
- Impact framebuffer (Oopes the kernel)
- Probably any PCI device plugged into the optional card cage

Unfortunately, I do not have the knowledge or capabilities to fix these, let alone the time needed to re-write some portions of the code to make these work properly. And that's not including the work needed to actually get this code into the mainline kernel.

So I'm looking for help from people that know the kernel a lot better than I, and don't mind a little bit of a challenge on getting this machine to work straight again. Maybe even help in some way to get it into an appropriate state to submit for inclusion in the kernel.

I've put the minimum three patches needed to get this machine to boot online at this address:
http://dev.gentoo.org/~kumba/mips/ip30_code/

Here's what each one does:

5011_2.6.30-ioc3-metadriver-r27.patch

This is a partial implementation of turning the IOC3 device in Octane (and also in Origin-class systems) into a bus of sorts. IOC3 on Octane governs access to the keyboard/mouse ports, ethernet controller, Real-time clock (a DS1687-5 chip), front panel LEDs, and probably the parallel port. It's not a fully-documented device, and violates the PCI spec in very unique ways, which requires special handling.

5012_2.6.22-ioc3-revert_commit_691cd0c.patch

This is a reversal of a patch committed to upstream almost 2 years ago (possibly longer), which broke IOC3 (when using the above metadriver) by making Linux enforce adherence to the PCI specification (I think, anyways. It's been too long). Without reversing this patch, none of the IOC3 sub-devices are accessible.

Original submission of it (with description) is here:
http://lkml.org/lkml/2007/1/26/67

5041_2.6.30-ip30-octane-support-r28.patch

This is the base code for the Octane port. I've largely maintained it via bandaid fixes, but even bandaids can't keep a ship from sinking forever. I managed to figure out the IRQ stuff to move Octane to using set_irq_and_chip_handler, which got it booting again, but this broke the Impact video driver, which will oops the kernel on initialization. SMP code broke back in 2.6.24 due to improper conversion to dyntick, and I've never been able to figure out why, because my only SMP CPU module turned out to have died while in storage.

So if anyone wants to help, take a look, and let me know if there are any questions. I'll answer what I can.

Thanks!,

Joshua Kinard
Gentoo/MIPS
[email protected]

"The past tempts us, the present confuses us, the future frightens us.  And our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

This is whats wrong with SMP: from file include/asm/mach-ip30/heart.h

#define HEART_IMR(x) ((volatile ulong *)0x900000000ff10000 + (8 * (x)))

I schould be

#define HEART_IMR(x) ((volatile ulong *)0x900000000ff10000 + (x))

or it schould be

#define HEART_IMR(x) ((volatile ulong *) (0x900000000ff10000 + (8 * (x))))

The IRQ MASK Register for the different CPUs are side by side.
In your version the factor 8 is used twice. First explicit inside the braces and second, because of the pointer to ulong implicit done by the compiler.
I checked it by dissambling the code and my smp-kernel is working if i start only with one cpu. With 2 cpus the smp-kernel is booting, but the init process hangs then.

the revert is not needed anymore, because of code in arch/mips/pci/ops-bridge.c look for the function emulate_ioc3_cfg

I hope it helps

i have done some more work on the older patches and have a working kernel. if someone wants this patch, i can send it.

bye

I'll have to test this when I get a new SMP module in. Found a cheap R10K (yuck) on eBay for real cheap that'll suffice. My R12000-300MHz refused to post at all (LED didn't even change to red, but the PROM would process NMI resets, oddly enough).

Ricardo (ricmm on IRC) explained it as this:

<ricmm> the baseline problem is that the secondary CPU's ipi irq is not triggering, the first one works <ricmm> and smp_call_function() is calling an init function on both CPUs with a wait_for_completion flag set <ricmm> but the second CPU will never run the function as the irq is not happening, therefore the flag will remain set <ricmm> and smp_call_function() will spin waiting for the completion

Awesome, that's great to know!

I'll take a look at it and see if I can integrate it into what I already have. Do you have it broken out into separate changes for the IOC3 metadriver and for the core IP30 code?

Thanks!

Joshua Kinard
Gentoo/MIPS
[email protected]

"The past tempts us, the present confuses us, the future frightens us.  And our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

i think i found the problem

try booting with a command line cca=5

the system is setting _page_cachable_default with what is found in the processor register at booting time which is 3 ( _CACHE_CACHABLE_NONCOHERENT ) i think this can not work on a SMP System.

with the above overriding i have a working SMP Octane system.

cca = 5 means _CACHE_CACHABLE_COHERENT

if time permits i send patches

bye

Tried this and the change to HEART_IMR on my end using a dual R10000 195MHz module. It didn't boot in any of the cases.

Joshua Kinard
Gentoo/MIPS
[email protected]

"The past tempts us, the present confuses us, the future frightens us.  And our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic