MPC8xx interrupts

Artemii S. Ivanov tema at oktet.ru
Tue Oct 23 14:42:45 UTC 2001


Hello, all MPC8xx users!

I have a question concerning interrupts processing -
as I see interrupt processing for MPC8xx is concentrated in
'irq' subdirectory of bsp directory (e.g. lib/libbsp/powerpc/mbx8xx/irq)
I think this code could be shared between differnet MPC8xx bsps (eth_comm
bsp use the same interrup processing code as mbx8xx bsp) and placed into
libcpu/powerpc/m8xx/ subdirectory.

Some usefull thing could be added to this interrupt dispatching code:
It seems that interrupt handler routine should have input parameter -
void interrupt_handler(void *arg),

Example - currently console-generic driver for m8xx has
3 interrupt handler routines (for scc2, scc3, scc4). They have
the same code, but registers are different (m8xx.scc2, m8xx.scc3,
m8xx.scc4). It will be rather simpler to have one interrupt handler -
m8xx_scc_interrupt_handler(scc_conf *conf_data), instead of
m8xx_scc2_interrupt_handler(void), m8xx_scc3..., etc....

Minimal changes should be applied to the current interrupt dispatching:
add args field into irq/irq.h, and replace rtems_hdl_tbl[irq].hdl()
by rtems_hdl_tbl[irq].hdl(args).


> This really should be discussed on the mailing list because
> it impacts a lot more users than you think.
>
> First, I think this is a good thing.
>
> My general rule of thumb is that you should add capabilities
> without breaking the current BSPs.  That means leaving the
> current settings as defaults and/or modifying the existing
> in-tree BSPs to provide proper settings.  In the case of
> the 8xx, you should also provide instructions on what to
> do to existing out-of-tree BSPs to keep current.
>
> --joel
>
> "Artemii S. Ivanov" wrote:
> >
> > Hello, Joel!
> >
> > I have stumbled with some problems during MPC860
> > RTEMS bsp development. I use eth_comm, and mbx8xx bsps, as
> > basis for work...
> >
> > 1). console-genric.c (libcpu/powerpc/m8xx/) looks as not
> > quite generic...
> >    a).Different boards could use differnt ports configurations
> >    (e.g. RXD3/4 could be achieved via port A, or port D), some chips(line
> >    drivers) need additional signals...
> >
> >    b). Baud Rate Generators distribution between SCCs.
> >    console-generic driver supports BRG allocation routine internally,
> >    but there could be BRG conflict between console and other dirvers that
> >    use SCC (e.g. Ethernet).
> >
> >    c). console-generic code could be significately reduced.
> >
> > 2). Generic ethenet driver.
> >     It seems that one could use generic ethernet driver (based on
> >     network.c from mbx8xx for example) with some improvements
> >     (see items a).b).c). from 1).)
> >
> > 3). Mmu initialization.
> >     Instruction and Data mmu initialization should be separated -
> >     Different memory attributes could be used.
> >     (currently Instruction and Data MMU use fill the same registers values
> >     from MMU_TLB_table).
> >
> > We're going to submit new variants for console and ethernet dirver, but
> > it arise some questions: what should be done for bsp that use current
> > drivers? should create new_console, new_mmu in order to save old variant,
> > or rewrite(remove) current m8xx bsp?
> >
> > Waiting for your comments.
> >
> > Thank you.
> >
> > Artemii S Ivanov.
> > Oktet Ltd. Russia.
>
>




More information about the users mailing list