gcj & PPC405

gcj & PPC405

[Patrick Olinet]

Hello all,

Is there anyone here with experience running gcj (gnu compiler for
java) compiled programs on a PPC405EP CPU ?

The native code produced by gcj runs fine on our embedded target
platform but it crashes when it has to interpret java byte code
("Illegal instruction" error message), although gcj has been compiled
with interpreter enabled.

gcj version is 3.4.3. linux kernel is 2.4.20. Unfortunately, it's hard
for us to upgrade any of them.

Any help would be really appreciated. Thanks in advance.

Regards,
Patrick Olinet

IRQ questions & puzzles

[Charles Krinke]

I have a linux-2.6.17.11 source tree that has configs for two boards.
One has an 8241 and the other has an 8541. The kernel code works fine on
the 8241, but appears to lock up in my custom driver in the 8541 when
interrupts are enabled.

What I see happening, based on using a BDI to go/halt after the apparent
lockup is that the kernel is spinning around in routines like
kernel/irq/handle.c:__do_IRQ and an associated
arch/powerpc/kernel/irq.c.

It looks like the interrupt, which should be level triggered and at this
point, is probably continuously asserted is causing the kernel to spin
in a tight loop and be incapable of doing printk's out the serial port
at 115200.

This leads to a few questions:

1. I can see most everything comes from arch/ppc, but do_IRQ comes from
arch/powerpc. Is that OK?

2. What is the most straightforward way to slow down a tight loop like
this slow enough so I can printk what is happening.

3. What might be the likely scenarios leading to such a despicable
state.

Charles Krinke

RE: IRQ questions & puzzles

[Charles Krinke]

Maybe I need to answer part of my question and ask another.

I can see, by putting a printk into ../kernel/irq/handle.c:__do_IRQ that
I normally get 3 interrupts with this 8541 board based on a
linux-2.6.17.11 kernel. A cat /proc/interrupts shows enet_rx on
interrupt 93, enet_tx on interrupt 94 and the serial port in interrupt
106.=20

I have a peripheral that sets irq to 16 and does a request_irq and this
works in the 8541 board. But on the 8541 board, the printk from inside
__do_IRQ shows the irq variable is zero, not 16.

Can someone please help me understand the care and feeding of external
interrupts in the 8541 a bit more completely?

Charles

-----Original Message-----
From: linuxppc-embedded-bounces+ckrinke=3Distor.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+ckrinke=3Distor.com@ozlabs.org] On
Behalf Of Charles Krinke
Sent: Thursday, April 26, 2007 11:36 AM
To: linuxppc-embedded@ozlabs.org
Cc: Randy Brown; Chris Carlson; Kevin Smith
Subject: IRQ questions & puzzles

I have a linux-2.6.17.11 source tree that has configs for two boards.
One has an 8241 and the other has an 8541. The kernel code works fine on
the 8241, but appears to lock up in my custom driver in the 8541 when
interrupts are enabled.

What I see happening, based on using a BDI to go/halt after the apparent
lockup is that the kernel is spinning around in routines like
kernel/irq/handle.c:__do_IRQ and an associated
arch/powerpc/kernel/irq.c.

It looks like the interrupt, which should be level triggered and at this
point, is probably continuously asserted is causing the kernel to spin
in a tight loop and be incapable of doing printk's out the serial port
at 115200.

This leads to a few questions:

1. I can see most everything comes from arch/ppc, but do_IRQ comes from
arch/powerpc. Is that OK?

2. What is the most straightforward way to slow down a tight loop like
this slow enough so I can printk what is happening.

3. What might be the likely scenarios leading to such a despicable
state.

Charles Krinke
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: IRQ questions & puzzles

[Jon Loeliger]

On Thu, 2007-04-26 at 13:36, Charles Krinke wrote:
> I have a linux-2.6.17.11 source tree that has configs for two boards.
> One has an 8241 and the other has an 8541. The kernel code works fine on
> the 8241, but appears to lock up in my custom driver in the 8541 when
> interrupts are enabled.

OK, let's back up a step.  The 8241 and the 8541 are
two very different parts.  Different PPC cores with very
different peripherals placed on two very likely different
boards as well.  So I am at a bit of a loss to understand
how you are comparing these two parts in casual comparison
like this.  You aren't suggesting that you are expecting
these to be the same in some way are you?

> What I see happening, based on using a BDI to go/halt after the apparent
> lockup is that the kernel is spinning around in routines like
> kernel/irq/handle.c:__do_IRQ and an associated
> arch/powerpc/kernel/irq.c.
> 
> It looks like the interrupt, which should be level triggered and at this
> point, is probably continuously asserted is causing the kernel to spin
> in a tight loop and be incapable of doing printk's out the serial port
> at 115200.
> 
> This leads to a few questions:

It certainly does! :-)

> 1. I can see most everything comes from arch/ppc, but do_IRQ comes from
> arch/powerpc. Is that OK?

"Most everything" for _which_ board?  The 8241 or the 8541?
Specifically, the former would easily still be arch/ppc based
while the latter _should_  be arch/powerpc based by now.
When compling arch/powerpc, only legacy #include files should
be being used during the build.

> 2. What is the most straightforward way to slow down a tight loop like
> this slow enough so I can printk what is happening.

Your BDI-2000, likely. :-)

> 3. What might be the likely scenarios leading to such a despicable
> state.

Initial PEBCAK, perhaps?  But yea, there may be a level difinition
problem on an line here.  Dunno yet, because the scenario seems a
bit strained or ill-described yet...

Any chance for a bit more clarity on what your situation is?

It seems to me that it is quite possible that many of these
issues might vanish with a 2.6.21 build straight up too.

HTH,
jdl

How do external irq's get mapped?

[Charles Krinke]

Let me try a more simplified IRQ question a different way by only
referring to the 8541.

There are 12 external interrupt sources, irq[0..11] and as I understand
it, they all go through one vector, ExternalInput set in
head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe
is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).

I am striving to understand how mapping of these external pins
irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".

Could someone point me at some references I can read to understand this
nuance of the 8541 in a linux-2.6.17.11 kernel, please.

Charles

Re: How do external irq's get mapped?

[Sergei Shtylyov]

Hello.

Charles Krinke wrote:

> Let me try a more simplified IRQ question a different way by only
> referring to the 8541.

> There are 12 external interrupt sources, irq[0..11] and as I understand
> it, they all go through one vector, ExternalInput set in
> head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe
> is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).

> I am striving to understand how mapping of these external pins
> irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".

    IIUC, the external IRQ #'s should follow those occupied by 32 internal IRQs.
    But those shown in that file are "virtual" numbers, i.e. they got re-mapped by the kernel as it sees fit (basically, it tries to assign the same # to IRQs above 15 and remaps those below)

> Could someone point me at some references I can read to understand this
> nuance of the 8541 in a linux-2.6.17.11 kernel, please.

   I'm not sure arch/powerpc/ in 2.6.17 had the complete MPC8541 support...

WBR, Sergei

Re: How do external irq's get mapped?

[Jon Loeliger]

On Fri, 2007-04-27 at 12:03, Sergei Shtylyov wrote:
> Hello.
> 
> Charles Krinke wrote:
> 
> > Let me try a more simplified IRQ question a different way by only
> > referring to the 8541.
> 
> > There are 12 external interrupt sources, irq[0..11] and as I understand
> > it, they all go through one vector, ExternalInput set in
> > head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe
> > is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).
> 
> > I am striving to understand how mapping of these external pins
> > irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".
> 
>     IIUC, the external IRQ #'s should follow those occupied by 32 internal IRQs.
>     But those shown in that file are "virtual" numbers, i.e. they got re-mapped by the kernel as it sees fit (basically, it tries to assign the same # to IRQs above 15 and remaps those below)

And remember, Ben distorted the IRQ World right about
somewhere in that time frame too.

Kumar, can you remind us?

> > Could someone point me at some references I can read to understand this
> > nuance of the 8541 in a linux-2.6.17.11 kernel, please.
> 
>    I'm not sure arch/powerpc/ in 2.6.17 had the complete MPC8541 support...

Which might be a different way of saying "You should try the
current top of git or 2.6.21." :-)

jdl

RE: How do external irq's get mapped?

[Charles Krinke]

-----Original Message-----
From: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com]=20
Sent: Friday, April 27, 2007 10:04 AM
To: Charles Krinke
Cc: Jon Loeliger; Randy Brown; Chris Carlson; Kevin Smith;
linuxppc-embedded@ozlabs.org
Subject: Re: How do external irq's get mapped?

Hello.

Charles Krinke wrote:

> Let me try a more simplified IRQ question a different way by only
> referring to the 8541.

> There are 12 external interrupt sources, irq[0..11] and as I
understand
> it, they all go through one vector, ExternalInput set in
> head_fsl_booke.S and this vector resolves to "do_IRQ()", which I
believe
> is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).

> I am striving to understand how mapping of these external pins
> irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".

    IIUC, the external IRQ #'s should follow those occupied by 32
internal IRQs.
    But those shown in that file are "virtual" numbers, i.e. they got
re-mapped by the kernel as it sees fit (basically, it tries to assign
the same # to IRQs above 15 and remaps those below)

> Could someone point me at some references I can read to understand
this
> nuance of the 8541 in a linux-2.6.17.11 kernel, please.

   I'm not sure arch/powerpc/ in 2.6.17 had the complete MPC8541
support...

WBR, Sergei

So would this mean that the external IRQ0 pin would map to irq #32 and
not irq #16 and the external IRQ11 pin would map to irq #43 and not irq
#27? So that if I want IRQ0, I would set my irq member of the pci_dev
struct to 32?

Charles=20

Re: How do external irq's get mapped?

[Sergei Shtylyov]

Charles Krinke wrote:

>>Let me try a more simplified IRQ question a different way by only
>>referring to the 8541.
 
>>There are 12 external interrupt sources, irq[0..11] and as I understand

>>it, they all go through one vector, ExternalInput set in
>>head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe
>>is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...).
 
>>I am striving to understand how mapping of these external pins
>>irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts".
 
>     IIUC, the external IRQ #'s should follow those occupied by 32
> internal IRQs.
>     But those shown in that file are "virtual" numbers, i.e. they got
> re-mapped by the kernel as it sees fit (basically, it tries to assign
> the same # to IRQs above 15 and remaps those below)
 
>>Could someone point me at some references I can read to understand this
>>nuance of the 8541 in a linux-2.6.17.11 kernel, please.

>    I'm not sure arch/powerpc/ in 2.6.17 had the complete MPC8541
> support...

> So would this mean that the external IRQ0 pin would map to irq #32 and
> not irq #16 and the external IRQ11 pin would map to irq #43 and not irq

   Where from is that #16?

> #27? So that if I want IRQ0, I would set my irq member of the pci_dev
> struct to 32?

   Yeah, unless MPC8541 has some complications like CPM.  And also note that I'm assuming 32 internal IRQs based on what MPC8540 has, not having MPC8541 specs...

> Charles 

WBR, Sergei

RE: How do external irq's get mapped?

[Charles Krinke]

As I understand it, the 8541 and 8555 have 12 external IRQ[0..11], 21
internal interrupts, and 4 messaging interrupts.

In looking at the MPC8555ERM.pdf file, which is my main resource, it
looks like the internal interrupt numbers for the 1st TSEC are 19 for
transmit and 20 for receive.

A 'cat /proc/interrupts' shows the 1st TSEC transmit as 93 and the
receive as 94, so I am puzzled how we get from 19 to 93 for the transmit
and from 20 to 94 for the receive. Perhaps understanding this will help
me figure out what number to put into the pci_dev structure for external
IRQ0.

At this particular moment, I can put 16, 32 or other numbers into the
pci_dev and do a request_irq for my driver in Linux-2.6.17.11. The
driver interrupts are enabled, but when "__do_IRQ" executes, its irq
variable is zero, which it should not be.

I can also see with a printk in this same "__do_IRQ" that the TSEC tx is
indeed 93, the TSEC rx is indeed 94 and the uart is 106.

Sorry to be a bit dense here, but understanding this is important to
moving forward.

Charles Krinke

Re: How do external irq's get mapped?

[Sergei Shtylyov]

Hello.

Charles Krinke wrote:
> As I understand it, the 8541 and 8555 have 12 external IRQ[0..11], 21
> internal interrupts, and 4 messaging interrupts.

> In looking at the MPC8555ERM.pdf file, which is my main resource, it
> looks like the internal interrupt numbers for the 1st TSEC are 19 for
> transmit and 20 for receive.

> A 'cat /proc/interrupts' shows the 1st TSEC transmit as 93 and the
> receive as 94, so I am puzzled how we get from 19 to 93 for the transmit
> and from 20 to 94 for the receive. Perhaps understanding this will help

   I'd suspect you also have CPM on this SoC (or have CONFIG_CPM* wrongly enabled?).

> me figure out what number to put into the pci_dev structure for external
> IRQ0.

   Could you post your /proc/interrupts?

 > Charles Krinke

WBR, Sergei

RE: How do external irq's get mapped?

[Charles Krinke]

> transmit and 20 for receive.

> A 'cat /proc/interrupts' shows the 1st TSEC transmit as 93 and the
> receive as 94, so I am puzzled how we get from 19 to 93 for the
transmit
> and from 20 to 94 for the receive. Perhaps understanding this will
help

   I'd suspect you also have CPM on this SoC (or have CONFIG_CPM*
wrongly enabled?).

> me figure out what number to put into the pci_dev structure for
external
> IRQ0.

   Could you post your /proc/interrupts?

 > Charles Krinke

WBR, Sergei

Dear Sergei:

Here is the result of /proc/interrupts

root@sff1:~# cat /proc/interrupts
           CPU0
  2:          0   i8259     Edge      82c59 secondary cascade
 32:          0   CPM2 SIU  Level     ichar
 93:      10701   OpenPIC   Level     enet_tx
 94:      13945   OpenPIC   Level     enet_rx
 98:          0   OpenPIC   Level     enet_error
106:        542   OpenPIC   Level     serial
107:          0   OpenPIC   Level     i2c-mpc
110:          0   OpenPIC   Level     cpm2_cascade
128:          0   OpenPIC   Level     <NULL>
BAD:          0
root@sff1:~#

The current issue is understanding how enet_tx, enet_rx & serial get to
be 93, 94 & 106 respectively. Once I understand that, I may have a clue
how to deal the one labelled ichar, which is the one that doesn't quite
work. This is a PCI chip our company designed.

Charles Krinke

RE: How do external irq's get mapped?

[Charles Krinke]

A little further on IRQ mapping. I was incorrect in saying enet_tx is at
19. According to MPC8555ERM.pdf the TSEC1_tx, TSEC_rx and DUART are at

13 TSEC1_tx   (maps to 93)
14 TSEC1_rx   (maps to 94)
26 DUART      (maps to 106)

A 'cat /proc/interrupts' shows this 93, 94 & 106 mapping:

root@sff1:~# cat /proc/interrupts
           CPU0
  2:          0   i8259     Edge      82c59 secondary cascade
 32:          0   CPM2 SIU  Level     ichar
 93:      10701   OpenPIC   Level     enet_tx
 94:      13945   OpenPIC   Level     enet_rx
 98:          0   OpenPIC   Level     enet_error
106:        542   OpenPIC   Level     serial
107:          0   OpenPIC   Level     i2c-mpc
110:          0   OpenPIC   Level     cpm2_cascade
128:          0   OpenPIC   Level     <NULL>
BAD:          0
root@sff1:~#

Looking at arch/ppc/platforms/85xx/mpc85xx_cds_common.c, I can see the
mpc85xx_cds_openpic[] array and since CONFIG_PCI is defined, the first
four entries for IRQ0..3 (or INTA, INTB, INTC & INTD) have non-zero
entries containing (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), which
should be OK.

Down a little further in this file is mpc85xx_cds_init_IRQ and it we do
not have CONFIG_MPC8548 defined, so we should be calling

openpic_set_sources(0, 32, OpenPIC_ADDR + 0x10200)=20

followed by calling=20

openpic_set_sources(48, 12, OpenPIC_ADDR + 0x10000)

This leads to a couple of new questions.

1. We have no 8259 in our design. Is this a concern as we are always
calling the i8259_init() routine.

2. The 'cat /proc/interrupts' shows 82c59 secondary cascade. Again, does
this matter?

3. The offset between TSEC1_tx of 13-->93 is a constant of 80 decimal.
Is this a clue to what the irq should be set to for external IRQ0 in
this design?

Charles Krinke

Re: How do external irq's get mapped?

[Andy Fleming]

On Apr 27, 2007, at 15:58, Charles Krinke wrote:

> A little further on IRQ mapping. I was incorrect in saying enet_tx  
> is at
> 19. According to MPC8555ERM.pdf the TSEC1_tx, TSEC_rx and DUART are at
>
> 13 TSEC1_tx   (maps to 93)
> 14 TSEC1_rx   (maps to 94)
> 26 DUART      (maps to 106)
>
> A 'cat /proc/interrupts' shows this 93, 94 & 106 mapping:

Ok that makes sense.
>
> root@sff1:~# cat /proc/interrupts
>            CPU0
>   2:          0   i8259     Edge      82c59 secondary cascade
>  32:          0   CPM2 SIU  Level     ichar
>  93:      10701   OpenPIC   Level     enet_tx
>  94:      13945   OpenPIC   Level     enet_rx
>  98:          0   OpenPIC   Level     enet_error
> 106:        542   OpenPIC   Level     serial
> 107:          0   OpenPIC   Level     i2c-mpc
> 110:          0   OpenPIC   Level     cpm2_cascade
> 128:          0   OpenPIC   Level     <NULL>
> BAD:          0
> root@sff1:~#
>
> Looking at arch/ppc/platforms/85xx/mpc85xx_cds_common.c, I can see the
> mpc85xx_cds_openpic[] array and since CONFIG_PCI is defined, the first
> four entries for IRQ0..3 (or INTA, INTB, INTC & INTD) have non-zero
> entries containing (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), which
> should be OK.


Are you using arch/ppc?  You should probably avoid that.  However, it  
does mean that you are probably using hard-coded irq offsets (rather  
than reading the numbers from the device tree.  What you are seeing  
is the result of adding the number of I8259 interrupts (16) to the  
number of CPM interrupts (64).  Then the internal interrupts start at  
80, and there are 32 of them, and the external interrupts would start  
at 112.  If you look at the arch/ppc code, it defines PIRQA-D, and  
they will be board-specific.


> This leads to a couple of new questions.
>
> 1. We have no 8259 in our design. Is this a concern as we are always
> calling the i8259_init() routine.


Yeah, don't do that.  Just wastes time, and could potentially screw  
around with something else on your bus.


>
> 2. The 'cat /proc/interrupts' shows 82c59 secondary cascade. Again,  
> does
> this matter?

That's potentially a big problem, as the 8259 cascade is hooked up to  
one of the external interrupts.  This might cause your kernel to  
interpret an interrupt as an i8259 interrupt, which could have all  
sorts of strange side-effects.


> 3. The offset between TSEC1_tx of 13-->93 is a constant of 80 decimal.
> Is this a clue to what the irq should be set to for external IRQ0 in
> this design?


Yeah.  112.  However, you really should switch to using arch/powerpc,  
and device trees.  In that instance, you set the irq to the pin  
number (1-4), and the kernel will map that based on the interrupt-map  
property of the pci node.  It was for precisely this type of problem  
that the irq numbers were virtualized.  The IRQ numbers in arch/ppc  
actually change depending on whether you've *configured* the CPM or not.

Andy

RE: How do external irq's get mapped?

[Charles Krinke]

> 3. The offset between TSEC1_tx of 13-->93 is a constant of 80 decimal.
> Is this a clue to what the irq should be set to for external IRQ0 in
> this design?


Yeah.  112.  However, you really should switch to using arch/powerpc, =20
and device trees.  In that instance, you set the irq to the pin =20
number (1-4), and the kernel will map that based on the interrupt-map =20
property of the pci node.  It was for precisely this type of problem =20
that the irq numbers were virtualized.  The IRQ numbers in arch/ppc =20
actually change depending on whether you've *configured* the CPM or not.

Andy

Dear Andy:

I appreciate your kind advice, it does help converge understanding
somewhat. I can see how we get the 80 decimal offset with 64 + 32.

I have commented out the call i8259_init(0,0) in
arch/ppc/platforms/85xx/mpc85xx_cds_common.c, but retained the call to
cpm2_init_IRQ(); shortly after that. We are constrained to finish the
current project with the kernel we started with, so changing from ppc to
powerpc is really difficult right now.

When the pci_dev->irq member is set to 112, there is a difference in
behavior. Now open_pic.c:720 is complaining that 112 is "invalid irq
112", so some additional understanding is needed on my part.

If you get a chance to help me continue to understand how the 8541
interrupts are sutured into Linux, it would be greatly appreciated.

Charles Krinke

RE: How do external irq's get mapped?

[Zhang Wei-r63237]

Hi, Charles,

Maybe you can try my patches about showing irq-mapping relationship.

http://patchwork.ozlabs.org/linuxppc/patch?id=3D9999
http://patchwork.ozlabs.org/linuxppc/patch?id=3D9997
http://patchwork.ozlabs.org/linuxppc/patch?id=3D9998
http://patchwork.ozlabs.org/linuxppc/patch?id=3D9996

Hope it could help you.

Best Regards,
Zhang Wei

> Subject: RE: How do external irq's get mapped?
>=20
> > 3. The offset between TSEC1_tx of 13-->93 is a constant of=20
> 80 decimal.
> > Is this a clue to what the irq should be set to for external IRQ0 in
> > this design?
>=20
>=20
> Yeah.  112.  However, you really should switch to using=20
> arch/powerpc, =20
> and device trees.  In that instance, you set the irq to the pin =20
> number (1-4), and the kernel will map that based on the=20
> interrupt-map =20
> property of the pci node.  It was for precisely this type of problem =20
> that the irq numbers were virtualized.  The IRQ numbers in arch/ppc =20
> actually change depending on whether you've *configured* the=20
> CPM or not.
>=20
> Andy
>=20
> Dear Andy:
>=20
> I appreciate your kind advice, it does help converge understanding
> somewhat. I can see how we get the 80 decimal offset with 64 + 32.
>=20
> I have commented out the call i8259_init(0,0) in
> arch/ppc/platforms/85xx/mpc85xx_cds_common.c, but retained the call to
> cpm2_init_IRQ(); shortly after that. We are constrained to finish the
> current project with the kernel we started with, so changing=20
> from ppc to
> powerpc is really difficult right now.
>=20
> When the pci_dev->irq member is set to 112, there is a difference in
> behavior. Now open_pic.c:720 is complaining that 112 is "invalid irq
> 112", so some additional understanding is needed on my part.
>=20
> If you get a chance to help me continue to understand how the 8541
> interrupts are sutured into Linux, it would be greatly appreciated.
>=20
> Charles Krinke
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20

I2C support for 8541

[Charles Krinke]

Assuming I have the external IRQ's understood, the next issue is the
hardware clock on our board with the linux-2.6.17.11 kernel. We are
using a "DS1338U", which is an I2C RTC.

I am trying to identify the relevant source for the 8541/8555 I2C
interface in the source base which reads/writes I2MOD, I2ADD, II2BRG,
I2COM, I2CER & I2CMR.

I can find a few references to MPC85xx_CPM_I2C in
../syslib/mpc85xx_devices.c, but nothing close in drivers/i2c/...

Can someone help me understand the completeness of the I2C source in the
2.6.17.11 kernel, please.

Charles Krinke

Re: I2C support for 8541

[Clemens Koller]

Hi, Charles!

Charles Krinke schrieb:
> Assuming I have the external IRQ's understood, the next issue is the
> hardware clock on our board with the linux-2.6.17.11 kernel. We are
> using a "DS1338U", which is an I2C RTC.

The I2C RTC drivers have changed in the latest kernels. You might
consider to update to some current 2.6.20+ kernel. On one of my
mpc8540's I get my RTC working right out of the box with an unpatched
vanilla kernel! :-)

Greets,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

Re: I2C support for 8541

[Vitaly Bordug]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Hello Charles,

On Mon, 30 Apr 2007 09:25:28 -0700
Charles Krinke wrote:

> Assuming I have the external IRQ's understood, the next issue is the
> hardware clock on our board with the linux-2.6.17.11 kernel. We are
> using a "DS1338U", which is an I2C RTC.
> 
> I am trying to identify the relevant source for the 8541/8555 I2C
> interface in the source base which reads/writes I2MOD, I2ADD, II2BRG,
> I2COM, I2CER & I2CMR.
> 
> I can find a few references to MPC85xx_CPM_I2C in
> ../syslib/mpc85xx_devices.c, but nothing close in drivers/i2c/...
> 
> Can someone help me understand the completeness of the I2C source in the
> 2.6.17.11 kernel, please.
> 

i2c-mpc.c is prolly responsible to care of 8xxx i2c stuff...

HTH
> Charles Krinke
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: How do external irq's get mapped?

[Charles Krinke]

At this point, I would just like to confirm I am thinking clearly and
now understand the IRQ mapping. We are constrained to finish this
project with the kernel we started with, linux-2.6.17.11, so this
discussion is centered around that code base. This is my understanding
based on last week's e-mails and my research.

1. In arch/ppc/platforms/85xx/mpc85xx_cds_common.c is the
mpc85xx_cds_openpic_initsenses[] whose first 4 members are set to
IRQ_SENSE_LEVEL or'ed with IRQ_POLARITY_NEGATIVE. This means the first
four external interrupts are enabled and neg polarity. I can use these
entries as is and change the others from 0x0 as I need more of the
external interrupt pins.

Just for reference, here are a few lines from mpc85xx_cds_init_IRQ

mpc85xx_cds_init_IRQ(void)
{
	openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
	/* Map PIC IRQs 0-11 */
	openpic_set_sources(48, 12, OpenPIC_Addr + 0x10000);
#if 0
	openpic_hookup_cascade(PIRQ0A, "82c59 cascade", i8259_irq);
	i8259_init(0, 0);
#endif
	/* Setup CPM2 PIC */
        cpm2_init_IRQ();
	setup_irq(MPC85xx_IRQ_CPM, &cpm2_irqaction);

2. In this routine, the first openpic_set_source call is for the 32
internal IRQ's and the second openpic_set_sources maps the 12 external
IRQ's beginning at 48, so that means my external IRQ mapping is:

ExtIrQ    LinuxIrqNum
0		48 (first four are enabled)
1		49
2		50
3		51
4		52 (last 8 not enabled by default)
5		53
6		54
7		55
8		56
9		57=09
10		58=09
11		59

Is this correct?

Charles

Re: How do external irq's get mapped?

[Andy Fleming]

On Apr 30, 2007, at 09:32, Charles Krinke wrote:

>
>
> At this point, I would just like to confirm I am thinking clearly and
> now understand the IRQ mapping. We are constrained to finish this
> project with the kernel we started with, linux-2.6.17.11, so this
> discussion is centered around that code base. This is my understanding
> based on last week's e-mails and my research.
>
> 1. In arch/ppc/platforms/85xx/mpc85xx_cds_common.c is the
> mpc85xx_cds_openpic_initsenses[] whose first 4 members are set to
> IRQ_SENSE_LEVEL or'ed with IRQ_POLARITY_NEGATIVE. This means the first
> four external interrupts are enabled and neg polarity. I can use these
> entries as is and change the others from 0x0 as I need more of the
> external interrupt pins.
>
> Just for reference, here are a few lines from mpc85xx_cds_init_IRQ
>
> mpc85xx_cds_init_IRQ(void)
> {
> 	openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
> 	/* Map PIC IRQs 0-11 */
> 	openpic_set_sources(48, 12, OpenPIC_Addr + 0x10000);


This line is almost more important:

         openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET);

You need to find out what that is defined to be.  My tree says it's  
defined as CPM_IRQ_OFFSET + NR_CPM_INTS (or 0, if CONFIG_CPM2 isn't  
defined).

So that's the 80, if NR_8259_INTS is 16.  Otherwise it's 64.  So 112  
could work, but if you have your config different, the numbers will  
move.


>
> 2. In this routine, the first openpic_set_source call is for the 32
> internal IRQ's and the second openpic_set_sources maps the 12 external
> IRQ's beginning at 48, so that means my external IRQ mapping is:
>
> ExtIrQ    LinuxIrqNum
> 0		48 (first four are enabled)
> 1		49
> 2		50
> 3		51
> 4		52 (last 8 not enabled by default)
> 5		53
> 6		54
> 7		55
> 8		56
> 9		57	
> 10		58	
> 11		59
>
> Is this correct?


Depends on your configuration.  But probably not.  The CPM takes up  
some space, too.

Andy

RE: How do external irq's get mapped?

[Charles Krinke]

Please pardon the top post, it is done to help my local compatriots read
more easily.

Andy, our MPC85xx_OPENPIC_IRQ_OFFSET is 80, but the call to
openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET) occurs after the two calls to
openpic_set_sources. This leads me to believe that the mapping goes

Internal irqs are 00..31 based on first openpic_set_sources(0, 32, ..)
External irqs are 48..60 based on second openpic_set_sources(48, 12,
...)

Then we have the openpic_init(80) call.

So, I though the external IRQ0 was mapped to 48. But is it really mapped
to 80 + 32 or 112 instead. If that is the case, there is another
problem.=20

The new problem is that if I set the irq to 112, when it is insmodded, I
get an error from open_pic.c of the form:

Open_pic.c:720 invalid irq 112

This seems to be coming from the macro at line 144 in open_pic.c

#define check_arg_irq(irq) \
    if (irq < open_pic_irq_offset || irq >=3D
NumSources+open_pic_irq_offset \
	|| ISR[irq - open_pic_irq_offset] =3D=3D 0) { \
      printk("open_pic.c:%d: invalid irq %d\n", __LINE__, irq); \
      dump_stack(); }

Charles




-----Original Message-----
From: Andy Fleming [mailto:afleming@freescale.com]=20
Sent: Monday, April 30, 2007 5:23 PM
To: Charles Krinke
Cc: Sergei Shtylyov; Randy Brown; Chris Carlson; Kevin Smith;
linuxppc-embedded@ozlabs.org
Subject: Re: How do external irq's get mapped?


On Apr 30, 2007, at 09:32, Charles Krinke wrote:

>
>
> At this point, I would just like to confirm I am thinking clearly and
> now understand the IRQ mapping. We are constrained to finish this
> project with the kernel we started with, linux-2.6.17.11, so this
> discussion is centered around that code base. This is my understanding
> based on last week's e-mails and my research.
>
> 1. In arch/ppc/platforms/85xx/mpc85xx_cds_common.c is the
> mpc85xx_cds_openpic_initsenses[] whose first 4 members are set to
> IRQ_SENSE_LEVEL or'ed with IRQ_POLARITY_NEGATIVE. This means the first
> four external interrupts are enabled and neg polarity. I can use these
> entries as is and change the others from 0x0 as I need more of the
> external interrupt pins.
>
> Just for reference, here are a few lines from mpc85xx_cds_init_IRQ
>
> mpc85xx_cds_init_IRQ(void)
> {
> 	openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
> 	/* Map PIC IRQs 0-11 */
> 	openpic_set_sources(48, 12, OpenPIC_Addr + 0x10000);


This line is almost more important:

         openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET);

You need to find out what that is defined to be.  My tree says it's =20
defined as CPM_IRQ_OFFSET + NR_CPM_INTS (or 0, if CONFIG_CPM2 isn't =20
defined).

So that's the 80, if NR_8259_INTS is 16.  Otherwise it's 64.  So 112 =20
could work, but if you have your config different, the numbers will =20
move.


>
> 2. In this routine, the first openpic_set_source call is for the 32
> internal IRQ's and the second openpic_set_sources maps the 12 external
> IRQ's beginning at 48, so that means my external IRQ mapping is:
>
> ExtIrQ    LinuxIrqNum
> 0		48 (first four are enabled)
> 1		49
> 2		50
> 3		51
> 4		52 (last 8 not enabled by default)
> 5		53
> 6		54
> 7		55
> 8		56
> 9		57=09
> 10		58=09
> 11		59
>
> Is this correct?


Depends on your configuration.  But probably not.  The CPM takes up =20
some space, too.

Andy

Re: How do external irq's get mapped?

[Andy Fleming]

On May 1, 2007, at 18:11, Charles Krinke wrote:

> Please pardon the top post, it is done to help my local compatriots  
> read
> more easily.
>
> Andy, our MPC85xx_OPENPIC_IRQ_OFFSET is 80, but the call to
> openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET) occurs after the two calls to
> openpic_set_sources. This leads me to believe that the mapping goes
>
> Internal irqs are 00..31 based on first openpic_set_sources(0, 32, ..)
> External irqs are 48..60 based on second openpic_set_sources(48, 12,
> ...)
>
> Then we have the openpic_init(80) call.
>
> So, I though the external IRQ0 was mapped to 48. But is it really  
> mapped
> to 80 + 32 or 112 instead. If that is the case, there is another
> problem.


Yeah, the set_sources functions just initialize the array of  
interrupts.  The openpic_init() actually gives them numbers and stuff.


>
> The new problem is that if I set the irq to 112, when it is  
> insmodded, I
> get an error from open_pic.c of the form:
>
> Open_pic.c:720 invalid irq 112
>
> This seems to be coming from the macro at line 144 in open_pic.c
>
> #define check_arg_irq(irq) \
>     if (irq < open_pic_irq_offset || irq >=
> NumSources+open_pic_irq_offset \
> 	|| ISR[irq - open_pic_irq_offset] == 0) { \
>       printk("open_pic.c:%d: invalid irq %d\n", __LINE__, irq); \
>       dump_stack(); }


Any  chance you can identify:

1) Where this macro is being called from when it fails

2) Which of the 3 conditions above are actually true

Andy

RE: How do external irq's get mapped?

[Charles Krinke]

> The new problem is that if I set the irq to 112, when it is =20
> insmodded, I
> get an error from open_pic.c of the form:
>
> Open_pic.c:720 invalid irq 112
>
> This seems to be coming from the macro at line 144 in open_pic.c
>
> #define check_arg_irq(irq) \
>     if (irq < open_pic_irq_offset || irq >=3D
> NumSources+open_pic_irq_offset \
> 	|| ISR[irq - open_pic_irq_offset] =3D=3D 0) { \
>       printk("open_pic.c:%d: invalid irq %d\n", __LINE__, irq); \
>       dump_stack(); }


Any  chance you can identify:

1) Where this macro is being called from when it fails

2) Which of the 3 conditions above are actually true

Andy

Dear Andy:

In our system, open_pic_irq_offset=3D80, numSources=3D60, *but* ISR[irq =
-
open_pic_irq_offset]=3DNULL when irq 112 is enabled.

It looks to me like each call to openpic_set_sources inits ISR[]
elements according to the first two arguments. We have two calls to
openpic_set_sources.=20

Internal irqs 00..31, 1st openpic_set_sources(0, 32) -- ISR[0..32]
External irqs 48..60, 2nd openpic_set_sources(48, 12) -- ISR[48..60]=20

But ISR[112] is never initialized in the source base.

I tried the cheap shot of adding a third openpic_set_sources(112, 12),
but I suspect the real answer is a bit more complicated then that.

Again, I thank you for your kind words while I struggle through this
external interrupt initalization for the PPC8541 in the Linux-2.6.17.11
kernel.

Charles Krinke

Re: How do external irq's get mapped?

[Andy Fleming]

On May 2, 2007, at 17:11, Charles Krinke wrote:

>> The new problem is that if I set the irq to 112, when it is
>> insmodded, I
>> get an error from open_pic.c of the form:
>>
>> Open_pic.c:720 invalid irq 112
>>
>> This seems to be coming from the macro at line 144 in open_pic.c
>>
>> #define check_arg_irq(irq) \
>>     if (irq < open_pic_irq_offset || irq >=
>> NumSources+open_pic_irq_offset \
>> 	|| ISR[irq - open_pic_irq_offset] == 0) { \
>>       printk("open_pic.c:%d: invalid irq %d\n", __LINE__, irq); \
>>       dump_stack(); }
>
>
> Any  chance you can identify:
>
> 1) Where this macro is being called from when it fails
>
> 2) Which of the 3 conditions above are actually true
>
> Andy
>
> Dear Andy:
>
> In our system, open_pic_irq_offset=80, numSources=60, *but* ISR[irq -
> open_pic_irq_offset]=NULL when irq 112 is enabled.
>
> It looks to me like each call to openpic_set_sources inits ISR[]
> elements according to the first two arguments. We have two calls to
> openpic_set_sources.
>
> Internal irqs 00..31, 1st openpic_set_sources(0, 32) -- ISR[0..32]
> External irqs 48..60, 2nd openpic_set_sources(48, 12) -- ISR[48..60]


Heh.  Whoops!  I didn't see the gap.  112-127 are, indeed, unmapped  
in this implementation.  Sorry about that.  You're going to want 80 
+48 = 128 for EXT0

>
> But ISR[112] is never initialized in the source base.
>
> I tried the cheap shot of adding a third openpic_set_sources(112, 12),
> but I suspect the real answer is a bit more complicated then that.


Yeah, that would set up interrupts from 192 to 203, which *also*  
don't exist.

Andy

RE: How do external irq's get mapped?

[Charles Krinke]

Dear Andy:

I want to thank you and your group for getting us off the externalIRQ
block. Using irq =3D 128 allows the external device to interrupt on IRQ0
to the 8541.

I know it was a long, drawn-out explanation, but the help in
understanding is much appreciated.

Charles Krinke