Help getting IP30/Octane fixed?

Help getting IP30/Octane fixed?

[Kumba]

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
kumba@gentoo.org

"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

Re: Help getting IP30/Octane fixed?

[Johannes Dickgreber]

Kumba schrieb:
> 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)
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.


> 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
> 
the revert is not needed anymore, because of code in arch/mips/pci/ops-bridge.c
look for the function emulate_ioc3_cfg
> 
> 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!,
> 
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  

Re: Help getting IP30/Octane fixed?

[Kumba]

Johannes Dickgreber wrote:

> 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.

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


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

Awesome, that's great to know!


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

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
kumba@gentoo.org

"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

Re: Help getting IP30/Octane fixed?

[Johannes Dickgreber]

Kumba schrieb:

> 
> 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
> 
> 
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 
 

Re: Help getting IP30/Octane fixed?

[Kumba]

Johannes Dickgreber wrote:
>
> 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 

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
kumba@gentoo.org

"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