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
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()
> 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.
> "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