Re: [ECOS] ARM vector.s -- suspicious code in return_from_exception

[Nick Garnett <nickg at ecoscentric dot com>]

"Michael Anburaj" <embeddedeng@hotmail.com> writes:

> Hi,
> 
> > > We probably haven't been bitten by this because I don't think we
> > > have any boards that make much use of FIQ.
> > >
> >
> >Most boards I've used with FIQ use their own VSR anyway.
> >
> 
> Just a thought!
> 
> The idea behind FIQs is to keep things simple along its code path. So
> that it can truly be a fast interrupt. All the FIQ code should do is
> handle the interrupt that caused it & return back to the previous
> mode. Task switch & things like that need not happen in a FIQ & the
> return path for this should be kept different from IRQ & need for
> switching to SVC mode & thus corrupting its SPSR can be
> avoided. Straight & simple FIQ path & the kernel need not be aware of
> FIQs.
> 

Exactly. In its original incarnation, the ARM HAL did not touch FIQ at
all, neither supplying any handling, nor masking it. It was left
entirely up to application code to handle. We did supply the jump
through the VSR table to make installation easier, but that was all.

Unfortunately, hardware is not always designed like that. Hardware
designers see that spare interrupt line and decide to hang arbitrary
devices off it. So over time we have had to add code to handle FIQs
through the same mechanism as IRQs, mask them at the same time as
the IRQ, and provide DSR handling so they can interact with eCos. The
result is that FIQs have become slower than IRQs. If people had paid
attention to the design specs of the ARM, we would not have had to do
that :-(

Users still have the option of installing their own VSR, however, so
not all is lost.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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