[ECOS] on ARM: Using the FIQ vector

[ECOS] on ARM: Using the FIQ vector

[Dan Hovang]

Hello,

I'm using the FIQ vector to process data which arrives at a very high
rate. My problem is that I'm unable to control the enable/disable FIQ
bit of the cpsr. At first, I figured it was just to exclude the FIQ
bit from the HAL_* macros but after some poking around I found that
the FIQ bit has a per-thread value which is set every time a new thread
is created (CPSR_THREAD_INITIAL in arm/arch/v1_2_1/src/hal_arch.h).

The only workaround I see would be to exclude the FIQ bit from
load_context in context.S aswell as from all relevant HAL_* macros.
It feels like kind of a 'hack' tough. Is there some code design with
the intention to solve this which I missed out?

/Dan

RE: [ECOS] on ARM: Using the FIQ vector

[Gary Thomas]

On 28-Jan-00 Dan Hovang wrote:
> Hello,
> 
> I'm using the FIQ vector to process data which arrives at a very high
> rate. My problem is that I'm unable to control the enable/disable FIQ
> bit of the cpsr. At first, I figured it was just to exclude the FIQ
> bit from the HAL_* macros but after some poking around I found that
> the FIQ bit has a per-thread value which is set every time a new thread
> is created (CPSR_THREAD_INITIAL in arm/arch/v1_2_1/src/hal_arch.h).
> 

Firstly, I'd suggest that you keep up with eCos development by using CVS.
Recent changes to the eCos source base are available via CVS, on a [more
or less] weekly basis.  The code base you're using is extremely old.

For details on using CVS, see http://sourceware.cygnus.com/ecos/

> The only workaround I see would be to exclude the FIQ bit from
> load_context in context.S aswell as from all relevant HAL_* macros.
> It feels like kind of a 'hack' tough. Is there some code design with
> the intention to solve this which I missed out?
> 

I'm a little confused about what you want to accomplish.  Are you interested
in masking _all_ FIQ interrupts or just one.  Perhaps if you could provide
a pseudo-code scenario, I can make some suggestions.

Re: [ECOS] on ARM: Using the FIQ vector

[Dan Hovang]

Gary Thomas wrote:
> 
> Firstly, I'd suggest that you keep up with eCos development by using
> CVS. Recent changes to the eCos source base are available via CVS,
> on a [more or less] weekly basis.  The code base you're using is
> extremely old.

I'm using the 1.2.1 (latest?) release sourcecode. I thought the cvs
code was purely development code, thus unstable and untested.

> I'm a little confused about what you want to accomplish.  Are you
> interested in masking _all_ FIQ interrupts or just one.  Perhaps if
> you could provide a pseudo-code scenario, I can make some suggestions.

I want to tell eCos "don't touch the disable FIQ bit of the cpsr, no
matter what". I've removed the default FIQ handling code since it
contains, from my point of view, a huge overhead. I get FIQ at about
400 kHz.

I've made a hack which solves my situation by adding this to context.S
(our platform is called Eye):

FUNC_START(hal_thread_load_context)
        ldr     fp,[r0]                 // get context to restore
        mrs     r0,cpsr                 // disable IRQ's
        orr     r0,r0,#CPSR_IRQ_DISABLE
        msr     cpsr,r0
#ifdef CYG_HAL_ARM_EYE // Don't touch the FIQ bit on Eye, DH 2000-01-28
        ands r1, r0, #CPSR_FIQ_DISABLE
#endif
        ldr r0,[fp,#armreg_cpsr]
#ifdef CYG_HAL_ARM_EYE
        biceq r0, r0, #CPSR_FIQ_DISABLE
        orrne r0, r0, #CPSR_FIQ_DISABLE
#endif
        msr     spsr,r0
        ldmfd   fp,{r0-r10,fp,sp,lr}    // also restores saved PSR
        movs    pc,lr

I've also modified the HAL macros which affects the cpsr, like this:

#ifdef CYG_HAL_ARM_EYE // FIQ should be excluded on platform eye
#define HAL_DISABLE_INTERRUPTS(_old_)           \
    asm volatile (                              \
        "mrs %0,cpsr;"                          \
        "mrs r4,cpsr;"                          \
        "orr r4,r4,#0x80;"                      \
        "msr cpsr,r4"                           \
        : "=r"(_old_)                           \
        :                                       \
        : "r4"                                  \
        );

But it would be nice if it was possible to have some more 'permanent'
solution which integrates well into eCos.

Also, I checked the anonymous cvs version of context.S and hal_intr.h
and I could not see any changes relevant to this issue.

/Dan

Re: [ECOS] on ARM: Using the FIQ vector

[Gary Thomas]

On 28-Jan-00 Dan Hovang wrote:
> Gary Thomas wrote:
>> 
>> Firstly, I'd suggest that you keep up with eCos development by using
>> CVS. Recent changes to the eCos source base are available via CVS,
>> on a [more or less] weekly basis.  The code base you're using is
>> extremely old.
> 
> I'm using the 1.2.1 (latest?) release sourcecode. I thought the cvs
> code was purely development code, thus unstable and untested.
> 

Not at all.  We have our own development tree for that :-)

The anonymous CVS tree which is available from our sourceware site is
a weekly snapshot from the development tree.  While the snapshot is
mostly automated, there is some care taken to make sure that what goes
there is fairly sane.  We do continuous quality checking of the eCos
source base, mostly based on what will end up in the external CVS tree.
You can feel fairly good about updating from CVS on a regular basis
if you want to keep up to date.

Re: [ECOS] on ARM: Using the FIQ vector

[Hugo 'NOx' Tyson]

Dan Hovang <dan.hovang@cpen.com> writes:
> I'm using the FIQ vector to process data which arrives at a very high
> rate. My problem is that I'm unable to control the enable/disable FIQ
> bit of the cpsr. At first, I figured it was just to exclude the FIQ
> bit from the HAL_* macros but after some poking around I found that
> the FIQ bit has a per-thread value which is set every time a new thread
> is created (CPSR_THREAD_INITIAL in arm/arch/v1_2_1/src/hal_arch.h).

Yeah; the interrupt state of the CPU (FIQ and IRQ bits in the CPSR) is
preserved on a per-thread basis, and since starting a new thread is no
different from resuming a descheduled one, it has to be initialized to
*something* in a new thread.  And there will be as many folks who like the
value for *something* we chose as don't like it ;-)
 
This is all OK because the intention is that the scheduler will only ever
be called when interrupts are enabled, so in fact the state being preserved
is a constant both sources enabled - the code works out neater that way.

> The only workaround I see would be to exclude the FIQ bit from
> load_context in context.S aswell as from all relevant HAL_* macros.
> It feels like kind of a 'hack' tough. Is there some code design with
> the intention to solve this which I missed out?

Yup, changing load_context so it does not not change the FIQ bit would
likely work.

BUT the recommended solution is that your hardware should have an interrupt
disable in it - akin to the interrupt controller that's typically attached
to IRQ.  So you control whether you get FIQs or not using your hardware
register, which obviously eCos knows nothing about.

Put another way:

 o short-term masking of *all* interrupts is done using the CPU register,
and you shouldn't let a thread that has done this sleep whilst interrupts
are disabled.  (Macros with ENABLE/DISABLE/RESTORE in them)
 o longer-term masking of *particular* interrupts is done using the PIC or
whatever the platform has.  (Macros with MASK/UNMASK in them and a vector)

It just *happens* that the CPU reg is preserved rather than always
re-enabled in load_context, because it doesn't really matter.

The PIC state is of course quite separate from the CPU state and scheduling
has no effect on it.

HTH,
	- Huge

-- 
The 20th Century brought unprecedented increases in worldwide numeracy and
literacy and incredible advances in technology, science and mathematics.
It was also the only century in the past or in any reasonable predictable
future apparently to contain only 99 years.

Re: [ECOS] on ARM: Using the FIQ vector

[Hugo 'NOx' Tyson]

I, Hugo 'NOx' Tyson <hmt@cygnus.co.ukx> said:
> > The only workaround I see would be to exclude the FIQ bit from
> > load_context in context.S aswell as from all relevant HAL_* macros.
> > It feels like kind of a 'hack' tough. Is there some code design with
> > the intention to solve this which I missed out?
> 
> Yup, changing load_context so it does not not change the FIQ bit would
> likely work.

Which reads back a bit confusing, I meant:

Yup, that 'hack' would probably work.
No, there is no code design for this.

	- Huge

-- 
The 20th Century brought unprecedented increases in worldwide numeracy and
literacy and incredible advances in technology, science and mathematics.
It was also the only century in the past or in any reasonable predictable
future apparently to contain only 99 years.

Re: [ECOS] on ARM: Using the FIQ vector

[Dan Hovang]

Hugo 'NOx' Tyson wrote:
> 
> Put another way:
> 
>  o short-term masking of *all* interrupts is done using the CPU
> register, and you shouldn't let a thread that has done this sleep
> whilst interrupts are disabled.  (Macros with ENABLE/DISABLE/RESTORE
> in them)

We need to be able to let the FIQ be enabled constantly, no exceptions.
I've removed the eCos FIQ code and rely on the IRQ to handle any timer
(scheduling) and devicedriver IRQ's. The goal is that it should be
enough to disable the IRQ in any critical sections of the kernel and
completely leave the FIQ to the application.

> It just *happens* that the CPU reg is preserved rather than always
> re-enabled in load_context, because it doesn't really matter.

It does to me, I think ... :-)

/Dan

Re: [ECOS] on ARM: Using the FIQ vector

[Gary Thomas]

On 28-Jan-00 Dan Hovang wrote:
> Hugo 'NOx' Tyson wrote:
>> 
>> Put another way:
>> 
>>  o short-term masking of *all* interrupts is done using the CPU
>> register, and you shouldn't let a thread that has done this sleep
>> whilst interrupts are disabled.  (Macros with ENABLE/DISABLE/RESTORE
>> in them)
> 
> We need to be able to let the FIQ be enabled constantly, no exceptions.
> I've removed the eCos FIQ code and rely on the IRQ to handle any timer
> (scheduling) and devicedriver IRQ's. The goal is that it should be
> enough to disable the IRQ in any critical sections of the kernel and
> completely leave the FIQ to the application.
> 
>> It just *happens* that the CPU reg is preserved rather than always
>> re-enabled in load_context, because it doesn't really matter.
> 
> It does to me, I think ... :-)
> 

I agree [somewhat] with this approach.  Currently FIQ interrupts are 
handled using the eCos interrupt structure.  While this works, in design,
it is probably too heavy weight for most FIQ interrupts (the emphasis
should be on _fast_).

What I have done in the past with FIQ interrupts (I was working with one
that has a 11KHz rate with little tolerance for delay) was to install
a different FIQ VSR, using the normal eCos support.  The only problem
left was the one Dan mentions that IRQ processing in the system also
can mask the FIQ.  I solved this ad hoc, similar to what Dan did, but
I think the proper solution is to have the FIQ support configurable in
the sytem such that systems that want total control over the FIQ can
get it without have to "hack" the sources.