This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM vector.s -- suspicious code in return_from_exception


Hello all,

Nice to see there is lots of support for the arm core.

>> Anyway, I think this patch fixes the problem you note above. I'll defer
>> checking it in to give others a chance to comment.

My comment:

- disable IRQ in exception handler
The theory is that after all pending interrupts are handled, interrupts are
enabled again and the corresponding dsr are called if requested by the interrupt
handlers. The dsr should only be called if an interrupt handler has too much
work or when kernel related functions are called within that interrupt. This way
the interrupt latency is kept small. Not re-enabling interrupts after handling
that interrupt will break that behaviour.
(The advantage of always disabling IRQ in supervisor mode is that the code can
be made simpler and faster)

- disable FIQ in exception handler
This will bring people into trouble as on some boards the FIQ is used outside
ecos. If we disable FIQ, the latency will increase. The simples method would be
to trigger an IRQ from FIQ, and handle the FIQ from there. However, there is no
universal way to do this. On the atmel board I can do this:
        .code   32
FIQ:
        // Mask FIQ in AIC (because we do not handle FIQ here)
        // it must be reenabled in user irq handler after the cause of FIQ is
resolved!
        ldr     r8, =AT91_AIC
        mov     r9, #1
        str     r9, [r8,#AT91_AIC_IMR]
        // Trigger AIC software interrupt (as FIQ has higher priority than IRQ,
it will not launch imediatly until after FIQ returns)
        mov     r9, #2
        str     r9, [r8,#AT91_AIC_ISCR]
        // Return from interrupt
        subs    pc, lr, #4
This will map the FIQ to the AIC software interrupt (*not* the same as the arm
software interrupt), which is then handled by an ecos interrupt handler. The AIC
software interrupt will launch as soon as FIQ returns. Now it is always possible
to register your own (fast) FIQ handler. Note: this code is not more expensive
than the current FIQ handler.
For other boards, I do not have a general solution. Anyone?

- for the atmel processors I have rewritten the interrupt handler to better use
the AIC (advanced interrupt controller) and to use interrupts outside ecos
untill a dsr is requested. This is an per-interrupt option, which I use only for
my own interrupts which are already debugged.  All other interrupts are still
handled the old way. Basicly I do not a mode switch, only save a few registers,
use a private stack and let the C code save other used resgisters. This makes
the handler much faster (by 10). If anyone is interested please let me know. The
disadvantage is that the general vector.s file has atmel specific code in it.

Eric



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]