All, Based on the replies, my question wasn't phrased precisely enough - possibly by underestimating how different our contexts are that we're operating in. Wouldn't be the first time!
What I was really asking was: does RTEMS expect from a BSP that interrupts will nest? Or doesn't it matter to the correct functioning of RTEMS? Or is it something more subtle like 'if interrupt set X is active, interrupt set Y must still be able to occur.' I gather it's (ideally?) the latter, where Y are based on the highest priority level in X. Which is fine for me, that's pretty close to the current state of the beagle code. I was having a hard time allowing X to occur (without infinite recursion) while X was still active. The active irq was probably masked implicitly in other BSPs I looked at. On Thu, May 1, 2014 at 7:53 PM, Chris Nott <[email protected]> wrote: > Ben, > > Just reviewing interrupts now. I'm not sure your question fully makes > sense. Unlike smaller embedded arms (eg. Cortex-M3), he interrupts on > Cortex-A8 are two-phase. There is an external (to the ARM core) interrupt > controller that feeds interrupts to the ARM IRQ and FIRQ lines. The ARM > process itself actually only has those two interrupt signals. > > It looks like the code currently handles IRQ and FIRQ serially, so any > interrupts at each level would be handled serially regardless of priority > set in the INTC. Presumably what we eventually want to do here for both IRQ > and FIRQ handlers is, receive the interrupt, immediately set the INTC > priority to the received interrupt level to block lower priority interrupts > (including the current interrupt), then acknowledge IRQ/FIRQ and dispatch > the actual interrupt handler at a lower CPU priority so we can nest > IRQ/FIRQ and handle higher priority interrupts. > > I'm not quite familiar with ARM family yet to be sure how this is normally > accomplished or if there is an existing supported ARM with the same > interrupt controller structure. TI provide sample source including > interrupt handler that supports this stuff. It might be a good place to > start playing with it, the source pretty much compiles fine in the RTEMS > environment. > > Chris. > > > > On 28/04/2014 4:32 AM, Ben Gras wrote: > > Dear all, > > I have a question about managing interrupts in a BSP that I have not been > able to answer satisfactorily by looking at other BSP code, nor looking > throught the documentation or googling. Or asking on the IRC channel :) > > My question is: are BSPs expected to allow nested interrupts? > Specifically, must bsp_interrupt_dispatch() turn interrupts on before > calling bsp_interrupt_handler_dispatch for everything else to work properly? > > Some BSPs do this, some don't. In the Beagle BSP I can do this by > masking the currently active interrupt and then enabling them at the CPU > level; but enabling all interrupts before the hw-specific handler is called > won't deassert the irq at the peripheral so I'm having trouble seeing how > that should work. > > Example: if we are in a timer ISR and loop on polling the uptime ticks, > do we expect the ticks to be able to increase? I'm wondering if any of the > remaining failing tests are due to this. But also what the best shape of a > BSP is. > > Thanks! > > > _______________________________________________ > rtems-devel mailing > [email protected]http://www.rtems.org/mailman/listinfo/rtems-devel > > > > _______________________________________________ > rtems-devel mailing list > [email protected] > http://www.rtems.org/mailman/listinfo/rtems-devel > >
_______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
