BSP question: nested interrupts?
Chris Nott
chrisn at vl.com.au
Thu May 1 17:53:53 UTC 2014
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 list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140501/f9d530df/attachment.html>
More information about the devel
mailing list