Interrupt unmask before complete cs8900a interrupt configuration.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Interrupt unmask before complete cs8900a interrupt configuration.

Jaws75
Hi all,
    I found a problem when I generated a net template image for my system.
The problem is related to the interrupt management beetwen the At91R40008
and the CS8900a.
In the if_cs8900a.c

static bool
cs8900a_init(struct cyg_netdevtab_entry *tab)
{

 ....

#ifdef CYGINT_IO_ETH_INT_SUPPORT_REQUIRED
    // Initialize environment, setup interrupt handler
    cyg_drv_interrupt_create(cpd->interrupt,
                             cpd->priority,
                             (cyg_addrword_t)cpd, //  Data item passed to
interrupt handler
                             (cyg_ISR_t *)cs8900a_isr,
                             (cyg_DSR_t *)cs8900a_dsr,
                             &cpd->interrupt_handle,
                             &cpd->interrupt_object);
    cyg_drv_interrupt_attach(cpd->interrupt_handle);
    cyg_drv_interrupt_acknowledge(cpd->interrupt);
    //cyg_drv_interrupt_unmask(cpd->interrupt);        //<---- I moved this
line in cs8900a_start ---->

the interrupt unmask occurs before the execution of cs8900a_start function
that configure the chip to generate the interrupt.
In this way a continuos loop on cs8900a_dsr happens.
The solution is to move the line below at the end of the function
cs8900a_start.
In this way the ethernet chip work fine.

Has anyone experimented this behaviour? Could be acceptable this patch?

Thanks
Jaws



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Interrupt unmask before complete cs8900a interrupt configuration.

Andrew Lunn-2
On Tue, Jan 10, 2006 at 05:11:07PM +0100, Jaws wrote:

> Hi all,
>     I found a problem when I generated a net template image for my system.
> The problem is related to the interrupt management beetwen the At91R40008
> and the CS8900a.
> In the if_cs8900a.c
>
> static bool
> cs8900a_init(struct cyg_netdevtab_entry *tab)
> {
>
>  ....
>
> #ifdef CYGINT_IO_ETH_INT_SUPPORT_REQUIRED
>     // Initialize environment, setup interrupt handler
>     cyg_drv_interrupt_create(cpd->interrupt,
>                              cpd->priority,
>                              (cyg_addrword_t)cpd, //  Data item passed to
> interrupt handler
>                              (cyg_ISR_t *)cs8900a_isr,
>                              (cyg_DSR_t *)cs8900a_dsr,
>                              &cpd->interrupt_handle,
>                              &cpd->interrupt_object);
>     cyg_drv_interrupt_attach(cpd->interrupt_handle);
>     cyg_drv_interrupt_acknowledge(cpd->interrupt);
>     //cyg_drv_interrupt_unmask(cpd->interrupt);        //<---- I moved this
> line in cs8900a_start ---->
>
> the interrupt unmask occurs before the execution of cs8900a_start function
> that configure the chip to generate the interrupt.

Why is it generating interrupts? By default devices should not
generate an interrupt until it is configured.

Are you using a bootload which uses the ethernet? Maybe the boot
loader has left the ethernet running when it jumps into eCos. This is
a bad idea. You have no idea what else it could be doing. I had a
college who spent a week tracking down a bug which killed a linux
system about 10 seconds into its boot process. He eventually found out
the boot loader left the ethernet chip running. While Linux was
booting the eithernet received a packet and DMAed it into the memory
buffer the bootload has allocated it, which happend to now contain the
uncompressed Linux image. Some seconds later Linux then "executed" the
received packet.....

So moving the unmask till later might help, but i think it would be
better to understand why you are getting interrupts in the first
place.

        Andrew


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Interrupt unmask before complete cs8900a interrupt configuration.

Jaws75
Hi Andrew,   thanks for your reply.
You are right,  when the application is launched the redboot is managing the
ethernet chip in polling mode, so the chip si configured.
What is your suggestion in this situation? I need to have the redboot
installed that launch the application, and I need also to have the ethernet
chip that works with redboot and with my application when it will be loaded.
How can I stop the ethernet chip before run the application?

Any suggestion is welcome.
Thanks
Jaws

----- Original Message -----
From: "Andrew Lunn" <[hidden email]>
To: "Jaws" <[hidden email]>
Cc: <[hidden email]>
Sent: Tuesday, January 10, 2006 6:12 PM
Subject: Re: [ECOS] Interrupt unmask before complete cs8900a interrupt
configuration.


> On Tue, Jan 10, 2006 at 05:11:07PM +0100, Jaws wrote:
> > Hi all,
> >     I found a problem when I generated a net template image for my
system.
> > The problem is related to the interrupt management beetwen the
At91R40008

> > and the CS8900a.
> > In the if_cs8900a.c
> >
> > static bool
> > cs8900a_init(struct cyg_netdevtab_entry *tab)
> > {
> >
> >  ....
> >
> > #ifdef CYGINT_IO_ETH_INT_SUPPORT_REQUIRED
> >     // Initialize environment, setup interrupt handler
> >     cyg_drv_interrupt_create(cpd->interrupt,
> >                              cpd->priority,
> >                              (cyg_addrword_t)cpd, //  Data item passed
to
> > interrupt handler
> >                              (cyg_ISR_t *)cs8900a_isr,
> >                              (cyg_DSR_t *)cs8900a_dsr,
> >                              &cpd->interrupt_handle,
> >                              &cpd->interrupt_object);
> >     cyg_drv_interrupt_attach(cpd->interrupt_handle);
> >     cyg_drv_interrupt_acknowledge(cpd->interrupt);
> >     //cyg_drv_interrupt_unmask(cpd->interrupt);        //<---- I moved
this
> > line in cs8900a_start ---->
> >
> > the interrupt unmask occurs before the execution of cs8900a_start
function

> > that configure the chip to generate the interrupt.
>
> Why is it generating interrupts? By default devices should not
> generate an interrupt until it is configured.
>
> Are you using a bootload which uses the ethernet? Maybe the boot
> loader has left the ethernet running when it jumps into eCos. This is
> a bad idea. You have no idea what else it could be doing. I had a
> college who spent a week tracking down a bug which killed a linux
> system about 10 seconds into its boot process. He eventually found out
> the boot loader left the ethernet chip running. While Linux was
> booting the eithernet received a packet and DMAed it into the memory
> buffer the bootload has allocated it, which happend to now contain the
> uncompressed Linux image. Some seconds later Linux then "executed" the
> received packet.....
>
> So moving the unmask till later might help, but i think it would be
> better to understand why you are getting interrupts in the first
> place.
>
>         Andrew
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Interrupt unmask before complete cs8900a interrupt configuration.

Gary Thomas
On Tue, 2006-01-10 at 18:38 +0100, Jaws wrote:
> Hi Andrew,   thanks for your reply.
> You are right,  when the application is launched the redboot is managing the
> ethernet chip in polling mode, so the chip si configured.
> What is your suggestion in this situation? I need to have the redboot
> installed that launch the application, and I need also to have the ethernet
> chip that works with redboot and with my application when it will be loaded.
> How can I stop the ethernet chip before run the application?

RedBoot already stops the network before it runs any program. (Of
course, this is based on the current CVS!)

>
> Any suggestion is welcome.
> Thanks
> Jaws
>
> ----- Original Message -----
> From: "Andrew Lunn" <[hidden email]>
> To: "Jaws" <[hidden email]>
> Cc: <[hidden email]>
> Sent: Tuesday, January 10, 2006 6:12 PM
> Subject: Re: [ECOS] Interrupt unmask before complete cs8900a interrupt
> configuration.
>
>
> > On Tue, Jan 10, 2006 at 05:11:07PM +0100, Jaws wrote:
> > > Hi all,
> > >     I found a problem when I generated a net template image for my
> system.
> > > The problem is related to the interrupt management beetwen the
> At91R40008
> > > and the CS8900a.
> > > In the if_cs8900a.c
> > >
> > > static bool
> > > cs8900a_init(struct cyg_netdevtab_entry *tab)
> > > {
> > >
> > >  ....
> > >
> > > #ifdef CYGINT_IO_ETH_INT_SUPPORT_REQUIRED
> > >     // Initialize environment, setup interrupt handler
> > >     cyg_drv_interrupt_create(cpd->interrupt,
> > >                              cpd->priority,
> > >                              (cyg_addrword_t)cpd, //  Data item passed
> to
> > > interrupt handler
> > >                              (cyg_ISR_t *)cs8900a_isr,
> > >                              (cyg_DSR_t *)cs8900a_dsr,
> > >                              &cpd->interrupt_handle,
> > >                              &cpd->interrupt_object);
> > >     cyg_drv_interrupt_attach(cpd->interrupt_handle);
> > >     cyg_drv_interrupt_acknowledge(cpd->interrupt);
> > >     //cyg_drv_interrupt_unmask(cpd->interrupt);        //<---- I moved
> this
> > > line in cs8900a_start ---->
> > >
> > > the interrupt unmask occurs before the execution of cs8900a_start
> function
> > > that configure the chip to generate the interrupt.
> >
> > Why is it generating interrupts? By default devices should not
> > generate an interrupt until it is configured.
> >
> > Are you using a bootload which uses the ethernet? Maybe the boot
> > loader has left the ethernet running when it jumps into eCos. This is
> > a bad idea. You have no idea what else it could be doing. I had a
> > college who spent a week tracking down a bug which killed a linux
> > system about 10 seconds into its boot process. He eventually found out
> > the boot loader left the ethernet chip running. While Linux was
> > booting the eithernet received a packet and DMAed it into the memory
> > buffer the bootload has allocated it, which happend to now contain the
> > uncompressed Linux image. Some seconds later Linux then "executed" the
> > received packet.....
> >
> > So moving the unmask till later might help, but i think it would be
> > better to understand why you are getting interrupts in the first
> > place.
> >
> >         Andrew
> >
> >
> > --
> > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> >
>

--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Interrupt unmask before complete cs8900a interrupt configuration.

Jaws75
If redboot stops the ethernet chip when lauch the application,
I don't understand why before the cs8900a_start, when unmask the interrupt,
it is active! The redboot is the current CVS version.
Any ideas?

Thanks
Jaws

----- Original Message -----
From: "Gary Thomas" <[hidden email]>
To: "Jaws" <[hidden email]>
Cc: "Andrew Lunn" <[hidden email]>; "eCos Discussion"
<[hidden email]>
Sent: Tuesday, January 10, 2006 6:44 PM
Subject: Re: [ECOS] Interrupt unmask before complete cs8900a interrupt
configuration.


> On Tue, 2006-01-10 at 18:38 +0100, Jaws wrote:
> > Hi Andrew,   thanks for your reply.
> > You are right,  when the application is launched the redboot is managing
the
> > ethernet chip in polling mode, so the chip si configured.
> > What is your suggestion in this situation? I need to have the redboot
> > installed that launch the application, and I need also to have the
ethernet
> > chip that works with redboot and with my application when it will be
loaded.

> > How can I stop the ethernet chip before run the application?
>
> RedBoot already stops the network before it runs any program. (Of
> course, this is based on the current CVS!)
>
> >
> > Any suggestion is welcome.
> > Thanks
> > Jaws
> >
> > ----- Original Message -----
> > From: "Andrew Lunn" <[hidden email]>
> > To: "Jaws" <[hidden email]>
> > Cc: <[hidden email]>
> > Sent: Tuesday, January 10, 2006 6:12 PM
> > Subject: Re: [ECOS] Interrupt unmask before complete cs8900a interrupt
> > configuration.
> >
> >
> > > On Tue, Jan 10, 2006 at 05:11:07PM +0100, Jaws wrote:
> > > > Hi all,
> > > >     I found a problem when I generated a net template image for my
> > system.
> > > > The problem is related to the interrupt management beetwen the
> > At91R40008
> > > > and the CS8900a.
> > > > In the if_cs8900a.c
> > > >
> > > > static bool
> > > > cs8900a_init(struct cyg_netdevtab_entry *tab)
> > > > {
> > > >
> > > >  ....
> > > >
> > > > #ifdef CYGINT_IO_ETH_INT_SUPPORT_REQUIRED
> > > >     // Initialize environment, setup interrupt handler
> > > >     cyg_drv_interrupt_create(cpd->interrupt,
> > > >                              cpd->priority,
> > > >                              (cyg_addrword_t)cpd, //  Data item
passed
> > to
> > > > interrupt handler
> > > >                              (cyg_ISR_t *)cs8900a_isr,
> > > >                              (cyg_DSR_t *)cs8900a_dsr,
> > > >                              &cpd->interrupt_handle,
> > > >                              &cpd->interrupt_object);
> > > >     cyg_drv_interrupt_attach(cpd->interrupt_handle);
> > > >     cyg_drv_interrupt_acknowledge(cpd->interrupt);
> > > >     //cyg_drv_interrupt_unmask(cpd->interrupt);        //<---- I
moved

> > this
> > > > line in cs8900a_start ---->
> > > >
> > > > the interrupt unmask occurs before the execution of cs8900a_start
> > function
> > > > that configure the chip to generate the interrupt.
> > >
> > > Why is it generating interrupts? By default devices should not
> > > generate an interrupt until it is configured.
> > >
> > > Are you using a bootload which uses the ethernet? Maybe the boot
> > > loader has left the ethernet running when it jumps into eCos. This is
> > > a bad idea. You have no idea what else it could be doing. I had a
> > > college who spent a week tracking down a bug which killed a linux
> > > system about 10 seconds into its boot process. He eventually found out
> > > the boot loader left the ethernet chip running. While Linux was
> > > booting the eithernet received a packet and DMAed it into the memory
> > > buffer the bootload has allocated it, which happend to now contain the
> > > uncompressed Linux image. Some seconds later Linux then "executed" the
> > > received packet.....
> > >
> > > So moving the unmask till later might help, but i think it would be
> > > better to understand why you are getting interrupts in the first
> > > place.
> > >
> > >         Andrew
> > >
> > >
> > > --
> > > Before posting, please read the FAQ:
http://ecos.sourceware.org/fom/ecos
> > > and search the list archive:
http://ecos.sourceware.org/ml/ecos-discuss

> > >
> >
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
>
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Interrupt unmask before complete cs8900a interrupt configuration.

Andrew Lunn-2
On Wed, Jan 11, 2006 at 11:48:36AM +0100, Jaws wrote:
> If redboot stops the ethernet chip when lauch the application,
> I don't understand why before the cs8900a_start, when unmask the interrupt,
> it is active! The redboot is the current CVS version.

The current code to stop the driver is:

static void
cs8900a_stop(struct eth_drv_sc *sc)
{
    cs8900a_priv_data_t *cpd = (cs8900a_priv_data_t *)sc->driver_private;
    cyg_addrword_t base = cpd->base;

    put_reg(base, PP_LineCTL, 0);
}

Is this enough to really stop the chip?

        Andrew


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Interrupt unmask before complete cs8900a interrupt configuration.

Gary Thomas
On Wed, 2006-01-11 at 13:05 +0100, Andrew Lunn wrote:

> On Wed, Jan 11, 2006 at 11:48:36AM +0100, Jaws wrote:
> > If redboot stops the ethernet chip when lauch the application,
> > I don't understand why before the cs8900a_start, when unmask the interrupt,
> > it is active! The redboot is the current CVS version.
>
> The current code to stop the driver is:
>
> static void
> cs8900a_stop(struct eth_drv_sc *sc)
> {
>     cs8900a_priv_data_t *cpd = (cs8900a_priv_data_t *)sc->driver_private;
>     cyg_addrword_t base = cpd->base;
>
>     put_reg(base, PP_LineCTL, 0);
> }
>
> Is this enough to really stop the chip?

It's enough to stop the chip from "talking".

I think Jaws has some other problem though - this chip has been used
on a wide variety of platforms and there has never been a problem
with interrupts before.  Perhaps the IRQ being used is shared with
some other piece of hardware which is asserting interrupts?

--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Interrupt unmask before complete cs8900a interrupt configuration.

Andrew Lunn-2
On Wed, Jan 11, 2006 at 05:15:28AM -0700, Gary Thomas wrote:

> On Wed, 2006-01-11 at 13:05 +0100, Andrew Lunn wrote:
> > On Wed, Jan 11, 2006 at 11:48:36AM +0100, Jaws wrote:
> > > If redboot stops the ethernet chip when lauch the application,
> > > I don't understand why before the cs8900a_start, when unmask the interrupt,
> > > it is active! The redboot is the current CVS version.
> >
> > The current code to stop the driver is:
> >
> > static void
> > cs8900a_stop(struct eth_drv_sc *sc)
> > {
> >     cs8900a_priv_data_t *cpd = (cs8900a_priv_data_t *)sc->driver_private;
> >     cyg_addrword_t base = cpd->base;
> >
> >     put_reg(base, PP_LineCTL, 0);
> > }
> >
> > Is this enough to really stop the chip?
>
> It's enough to stop the chip from "talking".

Does it stop the device from "listening"?

        Andrew


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Interrupt unmask before complete cs8900a interrupt configuration.

Gary Thomas
On Wed, 2006-01-11 at 13:34 +0100, Andrew Lunn wrote:

> On Wed, Jan 11, 2006 at 05:15:28AM -0700, Gary Thomas wrote:
> > On Wed, 2006-01-11 at 13:05 +0100, Andrew Lunn wrote:
> > > On Wed, Jan 11, 2006 at 11:48:36AM +0100, Jaws wrote:
> > > > If redboot stops the ethernet chip when lauch the application,
> > > > I don't understand why before the cs8900a_start, when unmask the interrupt,
> > > > it is active! The redboot is the current CVS version.
> > >
> > > The current code to stop the driver is:
> > >
> > > static void
> > > cs8900a_stop(struct eth_drv_sc *sc)
> > > {
> > >     cs8900a_priv_data_t *cpd = (cs8900a_priv_data_t *)sc->driver_private;
> > >     cyg_addrword_t base = cpd->base;
> > >
> > >     put_reg(base, PP_LineCTL, 0);
> > > }
> > >
> > > Is this enough to really stop the chip?
> >
> > It's enough to stop the chip from "talking".
>
> Does it stop the device from "listening"?

Yes - it matters little though since this device is programmed I/O
only (no DMA running wild, per your Linux bootup scenario...)

--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss