"OpenPIC versus EPIC" in MPC8240 !

"OpenPIC versus EPIC" in MPC8240 !

[Sarnath Kannan]

Dear reader,
 I am trying to enable interrupts on the sandpoint X2
board hosting MPC8240, in Mode 1.

I decided to use OPenPIC code (openpic.c) for EPIC,
as the  MPC8240 manual claims that EPIC is an OpenPIC standard. But I find some disparities between  the way EPIC's registers are organised and the way OpenPIC data
structures are declared.( openpic_defs.h )

According the OpenPIC data structure,
 "OpenPIC_Source" resides at offset 0x50000
 whereas the EPIC ( section 11 of MPC8240 manual)
says the it resides at 0x50200 ( See page 11-5)
 So, there is absolutely no gaurantee that
openPIC code would work for EPIC, Am i right ?

One more, If some1 could give me a clear picture
of interrupt routing on sandpoint board, it would
be very useful.
  From what i read, I have understood the following
Please correct me if I am wrong.

 1. The INTA ( used by Function  0 of Winbond -
    PCI/ISA bridge) is connected to IRQ0 of EPIC.

 2. The PCI interrupts (INTx) are  connected to the
    remaining PINs of EPIC in some order. ( I dont
    know which order they are connected )

Any help would be appreciated. Meanwhile, I am
reading the sandpoint manual also..( This one, I add
inorder to avoid replies like "RTFM")

Thanks for any help guys

Sarnath


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "OpenPIC versus EPIC" in MPC8240 !

[Dan Malek]

Sarnath Kannan wrote:

> Dear reader,
>  I am trying to enable interrupts on the sandpoint X2
> board hosting MPC8240, in Mode 1.

The Sandpoint interrupt structure for both X2 and X3 are supported
in the linuxppc kernel.  The MPC107/EPIC are supported on other boards
as well. Due to the way Linux supports interrupts, only one Sandpoint
board interrupt mode is supported.  Read the comments in
arch/ppc/kernel/sandpoint_setup.c for instructions.

There are many features of EPIC that are not currently supported using
the current OpenPIC functions, but it does work as a standard interrupt
controller on Sandpoint.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Re: "OpenPIC versus EPIC" in MPC8240 !

[Sarnath Kannan]

> It's not magic, just a bad software hack.  We tell the
> openpic that it has interrupts from 16 to 32, not from
> zero.  OpenPIC interrupt 16 matches EPIC interrupt zero.
   16-32 ? NumSources of OpenPIC = 24. It should be
either (0-23) or (16-40). 16-32 is noWhere.

> The interrupts zero to 15 are given to the 8259.
> The problem with this method is we can't get to some
> of the other EPIC features, but we are discussing
> alternatives.
>
  Its not a "HACK" dan. Its a bug. Just verify
the register layout of OpenPIC and EPIC. You
will find that "openpic_init" is populating
reserved memory areas of EPIC. No wonder, we get
bogus interrupts. You can verify this in the code.
  Moreover Had the code really wanted seperation
of vector spaces of OpenPIC and EPIC, it should have
called "openpic_init" with
"offset value = "NUM_8259_INTERRUPTS"

sarnath


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "OpenPIC versus EPIC" in MPC8240 !

[ashish anand]

Sarnath Kannan wrote:

sorry for jumping in between as i was out on long leave.
there is absoluetely no relation of bogus interrupts
with "openpic_init" is populating reserved memory areas of EPIC.

even i agree "openpic_init" is populating reserved memory areas of EPIC may
need a second thought.
you should refrain from saying so firmly without tech. support for that.

Best Regards
Ashish

>   Its not a "HACK" dan. Its a bug. Just verify
> the register layout of OpenPIC and EPIC. You
> will find that "openpic_init" is populating
> reserved memory areas of EPIC. No wonder, we get
> bogus interrupts. You can verify this in the code.
>   Moreover Had the code really wanted seperation
> of vector spaces of OpenPIC and EPIC, it should have
> called "openpic_init" with
> "offset value = "NUM_8259_INTERRUPTS"

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "OpenPIC versus EPIC" in MPC8240 !

[Dan Malek]

Sarnath Kannan wrote:

> Hi Ashish,
>   what I felt was, populating reserved areas
> is a bug.

It's only a bug if we don't know we are doing this and
it is causing problems.  We know we can do what we
are doing without trouble.  I'm not trying to
justify this hack or claim it is the proper solution.
It just happens to work, allows us to take advantage of
existing software functions, and someday it may be changed.

When someone like you shows up and your only concern or
contribution is to fix this function, then do it.  I don't
want to hear why you think someone else did it wrong or what
someone else should do to make it better.  Just fix the damn
thing!  When someone like me is trying to do hundreds of things
to get a board port done, using any existing code is exactly
what I'm going to do.  For EPIC I could take advantage of a
bunch of existing code instead of discussing why it should
change, or rewriting and testing on a whole bunch of other platforms
that doesn't help me make progress.  If you have the time to
rewirte and test it on _everything_ affected, go right ahead.


> I has said that this could be a __possible__
> cause for getting bogus interrupts. I would
> say there is 80% possibility.

You are just digging a deeper hole.  Bugs are either 100% there
or not there at all.  There isn't an 80% possibility of a bug.......
The _conditions_ under which a bug can appear are variable,
but a bug is a bug.

>  Moreover if u can read the EPIC manual,
> u can notice that IVPR and SVPR both start
> at  offset 0x50200. ( So the IVPR space is
> not a continous 24 entries. It is actually
> overalapped and discontinous )

If you actually _understood_ what you read, you would notice
this register space has different functions depending upon
the configuration of the EPIC and the design of the hardware
surrounding it.  You will also notice that because of the way
we initialize and utilize the openpic and interrupt management
functions that we properly configure the interrupt source registers
for the board design.

>   I have no idea of hurting people. But if a bug
> is pointed out, there is no harm in accepting it.

More importanly, you should do something constructive and fix it.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "OpenPIC versus EPIC" in MPC8240 !

[Dag Nygren]

> >   I have no idea of hurting people. But if a bug
> > is pointed out, there is no harm in accepting it.
>
> More importanly, you should do something constructive and fix it.

I thiught I did that, but noone seems to be interested.. ;-)

Dag


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "OpenPIC versus EPIC" in MPC8240 !

[Dan Malek]

Dag Nygren wrote:


> I thiught I did that, but noone seems to be interested.. ;-)

Yeah :-).  I was hoping Paul or someone else would make a suggestion.
A few of us (and people more interested and affected by OpenPIC other
than me) had discussed some other, slightly more pleasing hacks.....
Right now I'm swamped with other projects, although I have some
Sandpoint work on my list and when I do that I will incorporate
what you have done.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "OpenPIC versus EPIC" in MPC8240 !

[Dag Nygren]

> Dag Nygren wrote:
>
>
> > I thiught I did that, but noone seems to be interested.. ;-)
>
> Yeah :-).  I was hoping Paul or someone else would make a suggestion.
> A few of us (and people more interested and affected by OpenPIC other
> than me) had discussed some other, slightly more pleasing hacks.....
> Right now I'm swamped with other projects, although I have some
> Sandpoint work on my list and when I do that I will incorporate
> what you have done.
>
> Thanks.

Thanks to you,

i know it is not perfect, but it certainly is better than the
current solution...

Dag


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "OpenPIC versus EPIC" in MPC8240 !

[James F Dougherty]

I've been watching this thread for quite some
time now. I spoke with Dan about adding some
changes to this code last summer. I ran into
some issues with OpenPIC as well on our MPC8240
platform.


If you guys would like to forward me your changes,
I can merge your changes into mine (or see if they
are relevant) and give you an interim release.

Might I ask, could you describe the architecture
of your MPC8240 IRQ mapping and IO devices?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "OpenPIC versus EPIC" in MPC8240 !

[Dag Nygren]

>
> I've been watching this thread for quite some
> time now. I spoke with Dan about adding some
> changes to this code last summer. I ran into
> some issues with OpenPIC as well on our MPC8240
> platform.
>
>
> If you guys would like to forward me your changes,
> I can merge your changes into mine (or see if they
> are relevant) and give you an interim release.
>
> Might I ask, could you describe the architecture
> of your MPC8240 IRQ mapping and IO devices?

My changes doesn't specifically touch the MPC8240 code
but are included in my port for ths VG4-board.
This board uses a MPC107, which also is an EPIC.
The stuff was posted in this NG (and also linux-developers)
and I think you can find it there. If not give me another
mail , and I will send it to you.

What it does is really only changing the interface to
openpic_init() to something more versatile/generic/useful(?).

The interface structure could/should probably be further
abstracted to multilevel cascades (any of those out there ?)
as Dan sort of pointed out, but this is a start anyway.

The appropriate files for you from the port should be
the following:
openpic2.c and openpic2.h.

You could check the vg4_setup.c for an example of
how to use the interface.

Your mileage may vary, but it works perfectly on my board.

BRGDS

Dag


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/