[ECOS] interrupt handlers for the ARM SA1110

[ECOS] interrupt handlers for the ARM SA1110

[Warren Jasper]

This is a directed to Gary Thomas, but any comments are welcome.

I have ported eCos to a development board with a BOPS's DSP and the
Intel SA1110.  The DSP has it's own interrupt controller (with 32
vectors or causes), so I would like to "cascade" that onto the current
port.  I am using GPIO6 and GPIO7 as interrupts from the DSP's
controller (ie, when the DSP's interrupt controller is configured
properly, GPIO6 will go high on a DSP interrupt).

My question is where or how is the best way to do this?  I looked in
sa11X0/var/current/src/sa11X0_misc.c as see some of the hooks, but am
unsure how to either override or append to that.  I need to set up a
secondary level of interrupts, which I would like to do in the HAL,
and not in the application code.  Where is the best place to append
more vectors?  If the name of my board is travis, do I have a
sa11x0/travis/current/plf_intr.h or hal_intr.h?  How does that
interface or override the one in sa11x0/var/current/{include,src} ?

I would rather not have to modify the var files so my cvs tree remains
consistant.

Where is the isr_springboard table like in the mips vrc4373 port?  I have ported
the BOPS's DSP to another board running the QED rm5231 MIPS CPU, so I thought
I was familiar with the basic eCos model for the HAL.

Also, what is the difference between say hal_interrupt_mask and
HAL_INTERRUPT_MASK other than the obvious that one is a function and
the other a macro.  Which one over-rides the other and where.


Thanks in advance,

	-- Warren

Warren J. Jasper
wjasper@tx.ncsu.edu

Re: [ECOS] interrupt handlers for the ARM SA1110

[Jonathan Larmour]

Warren Jasper wrote:
> 
> I have ported eCos to a development board with a BOPS's DSP and the
> Intel SA1110.  The DSP has it's own interrupt controller (with 32
> vectors or causes), so I would like to "cascade" that onto the current
> port.  I am using GPIO6 and GPIO7 as interrupts from the DSP's
> controller (ie, when the DSP's interrupt controller is configured
> properly, GPIO6 will go high on a DSP interrupt).
> 
> My question is where or how is the best way to do this?  I looked in
> sa11X0/var/current/src/sa11X0_misc.c as see some of the hooks, but am
> unsure how to either override or append to that.  I need to set up a
> secondary level of interrupts, which I would like to do in the HAL,
> and not in the application code.  Where is the best place to append
> more vectors?  If the name of my board is travis, do I have a
> sa11x0/travis/current/plf_intr.h or hal_intr.h?  How does that
> interface or override the one in sa11x0/var/current/{include,src} ?
>
> I would rather not have to modify the var files so my cvs tree remains
> consistant.
 
If you need to change hal_IRQ_handler, the only way to override it is by
changing something in the var stuff. That's a key benefit of open source!
 
> Where is the isr_springboard table like in the mips vrc4373 port?  I have ported
> the BOPS's DSP to another board running the QED rm5231 MIPS CPU, so I thought
> I was familiar with the basic eCos model for the HAL.

Except that hardware can have very different interrupt models and interrupt
controllers making a single solution impossible. In this case, the decoding
is in hal_IRQ_handler.
 
> Also, what is the difference between say hal_interrupt_mask and
> HAL_INTERRUPT_MASK other than the obvious that one is a function and
> the other a macro.  Which one over-rides the other and where.

HAL_INTERRUPT_MASK is the official exported HAL API macro. Use grep for the
rest!

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

RE: [ECOS] interrupt handlers for the ARM SA1110

[Gary Thomas]

On 18-Jul-2001 Warren Jasper wrote:
> 
> This is a directed to Gary Thomas, but any comments are welcome.
> 

Why me?

> I have ported eCos to a development board with a BOPS's DSP and the
> Intel SA1110.  The DSP has it's own interrupt controller (with 32
> vectors or causes), so I would like to "cascade" that onto the current
> port.  I am using GPIO6 and GPIO7 as interrupts from the DSP's
> controller (ie, when the DSP's interrupt controller is configured
> properly, GPIO6 will go high on a DSP interrupt).
> 
> My question is where or how is the best way to do this?  I looked in
> sa11X0/var/current/src/sa11X0_misc.c as see some of the hooks, but am
> unsure how to either override or append to that.  I need to set up a
> secondary level of interrupts, which I would like to do in the HAL,
> and not in the application code.  Where is the best place to append
> more vectors?  If the name of my board is travis, do I have a
> sa11x0/travis/current/plf_intr.h or hal_intr.h?  How does that
> interface or override the one in sa11x0/var/current/{include,src} ?
> 

This would be in hal/arm/sa11x0/travis/current/hal_platform_ints.h
(yes, these files are not terribly consistent)  You can add the additional
interrupts from the DSP beyond the normal interrupts.  

As for your cascaded interrupt, all of this support can be handled in
your platform code (look at hal/arm/sa11x0/ipaq/current/src/ipaq_misc.c
for some examples).  

Handling the actual interrupt vectors for your additional sources would
involve some changes to the common (/var) code.  This can be added 
without too much perturbation, something like this:


void hal_interrupt_unmask(int vector)
{
#ifdef HAL_EXTENDED_INTERRUPT_UNMASK
    HAL_EXTENDED_INTERRUPT_UNMASK(vector)
#endif
    if (vector >= CYGNUM_HAL_INTERRUPT_GPIO11) {
        vector = CYGNUM_HAL_INTERRUPT_GPIO;
    }
    *SA11X0_ICMR |= (1 << vector);
}

Where (in your platform interrupt file) you'd define 

#define HAL_EXTENDED_INTERRUPT_UNMASK
    if (vector >= CYGNUM_HAL_INTERRUPT_DSP0) {
       // Do whatever is required
       return;
    }

Hopefully you get the picture.  Such additions to the common code would
be accepted back into the mainline by us and you'd have the support you
need.

> I would rather not have to modify the var files so my cvs tree remains
> consistant.
> 
> Where is the isr_springboard table like in the mips vrc4373 port?  I have ported
> the BOPS's DSP to another board running the QED rm5231 MIPS CPU, so I thought
> I was familiar with the basic eCos model for the HAL.
> 

The notion of 'isr_springboard' is unique to the MIPS.  Other processors
have different ways of handling low level interrupt vectoring code, thus
the setup is different.

> Also, what is the difference between say hal_interrupt_mask and
> HAL_INTERRUPT_MASK other than the obvious that one is a function and
> the other a macro.  Which one over-rides the other and where.

The HAL requires the macro(s), but the implementation of these functions
on the ARM are via functions, such as hal_interrupt_mask().

Re: [ECOS] interrupt handlers for the ARM SA1110

[Gary Thomas]

Note: as a matter of policy, these discussions should be copied to
the ecos-discuss list.  Mail sent directly to developers without
also being copied can and often will be ignored.  [It's for the
good of everyone]

On 18-Jul-2001 Warren Jasper wrote:
> Hi Gary,
> 
>>
>>On 18-Jul-2001 Warren Jasper wrote:
>>> 
>>> This is a directed to Gary Thomas, but any comments are welcome.
>>> 
>>
>>Why me?
> 
> Because your name is on the hal code that I'm interested in :)
> 
> [snip]
> 
>>This would be in hal/arm/sa11x0/travis/current/hal_platform_ints.h
>>(yes, these files are not terribly consistent)  You can add the additional
>>interrupts from the DSP beyond the normal interrupts.  
> 
> OK, let me get this straight.  If I have a file  
> 
> hal/arm/sa11x0/travis/current/include/hal_platform_ints.h
> 
> then that will get included instead of  [in addition to?]
> 
> hal/arm/sa11x0/var/current/include/hal_var_ints.h ???
> 
> I've been grepping around, but I'm not clear on this little bit.
> 

Look in hal/arm/arch/current/include/hal_intr.h  - there is sufficient
mechanism in there to allow a platform to override the variant defaults.

> 
>>As for your cascaded interrupt, all of this support can be handled in
>>your platform code (look at hal/arm/sa11x0/ipaq/current/src/ipaq_misc.c
>>for some examples).  
>>
>>Handling the actual interrupt vectors for your additional sources would
>>involve some changes to the common (/var) code.  This can be added 
>>without too much perturbation, something like this:
>>
>>
>>void hal_interrupt_unmask(int vector)
>>{
>>#ifdef HAL_EXTENDED_INTERRUPT_UNMASK
>>    HAL_EXTENDED_INTERRUPT_UNMASK(vector)
>>#endif
>>    if (vector >= CYGNUM_HAL_INTERRUPT_GPIO11) {
>>        vector = CYGNUM_HAL_INTERRUPT_GPIO;
>>    }
>>    *SA11X0_ICMR |= (1 << vector);
>>}
>>
>>Where (in your platform interrupt file) you'd define 
>>
>>#define HAL_EXTENDED_INTERRUPT_UNMASK
>>    if (vector >= CYGNUM_HAL_INTERRUPT_DSP0) {
>>       // Do whatever is required
>>       return;
>>    }
>>
>>Hopefully you get the picture.  Such additions to the common code would
>>be accepted back into the mainline by us and you'd have the support you
>>need.
> 
> Yes, that is an excellent suggestion.  I need a few days to check out
> my HAL and debug it with the extended exception handler.  Then I'll
> send you my copy of the file:
> 
> hal/arm/sa11x0/var/current/src/sa11x0_misc.c 
> 
> with the hooks for board extended functionality as you suggested.
> 

I'll be glad to look at whatever you come up with.

Re: [ECOS] interrupt handlers for the ARM SA1110

[Warren Jasper]

>> 
>> OK, let me get this straight.  If I have a file  
>> 
>> hal/arm/sa11x0/travis/current/include/hal_platform_ints.h
>> 
>> then that will get included instead of  [in addition to?]
>> 
>> hal/arm/sa11x0/var/current/include/hal_var_ints.h ???
>> 
>> I've been grepping around, but I'm not clear on this little bit.
>> 
>
>Look in hal/arm/arch/current/include/hal_intr.h  - there is sufficient
>mechanism in there to allow a platform to override the variant defaults.

Thanks.  I just need to add to my cdl file:

    define_proc {
        puts $::cdl_header \
       "#define CYGBLD_HAL_PLF_INTS_H <cyg/hal/hal_platform_ints.h>"
    }

	-- Warren

Warren J. Jasper
wjasper@tx.ncsu.edu

[ECOS] interrupt handlers for the ARM SA1110

[Warren Jasper]

I have a few comments and a suggestion.

Per Gary Thomas's suggestion, I have added  some hooks to the file
/hal/arm/sa11x0/var/current/src/sa11x0_misc.c so that I could extend the

hal_interrupt_handle table to include 32 extra interrupts from my DSP.
The file
is attached.   Changes are like:

/* macro for board specific IRQ handler */
#ifdef HAL_EXTENDED_IRQ_HANDLER
      HAL_EXTENDED_IRQ_HANDLER(index);
 #endif

Please consider wrapping these changes into the main distribution.
That way, hooks will be
available for other variants of the sa11x0  to incorporate extra
interrupts.

The user needs to replace
hal/arm/sa11x0/var/current/include/hal_var_ints.h with
a modified version:
hal/arm/sa11x0/variant_board_hal/include/platform_hal_ints.h

and in the cdl for the variant, include the lines:

    define_proc {
        puts $::cdl_header \
       "#define CYGBLD_HAL_PLF_INTS_H <cyg/hal/hal_platform_ints.h>"
    }

Unfortunately, doing this may or may not work.  There is a somewhat
cryptic comment
(I guess cryptic comments are better than no comments ???) in
/hal/arm/arch/current/src/vectors.S  near the end:

//
-------------------------------------------------------------------------

// Interrupt vector tables.
// These tables contain the isr, data and object pointers used to
deliver
// interrupts to user code.

// Despite appearances, their sizes are not #defines, but .equ symbols
// generated by magic without proper dependencies in arm.inc
// Recompiling will not DTRT without manual intervention.

        .data

init_flag:
        .balign 4
        .long   0

 .extern hal_default_isr

 .globl  hal_interrupt_handlers
hal_interrupt_handlers:
        .rept   CYGNUM_HAL_ISR_COUNT
        .long   hal_default_isr
        .endr

Once  CYGNUM_HAL_ISR_COUNT is redefined, it sure would be nice to know
exactly how to
 increase the size of the table, and to know up front that the following
wont' work:

ecosconfig tree
make clean
make

I ended up disassembling the code and counting the size of
hal_interrupt_handlers before I
felt confident that that size of the table (which is kind of important)
was what I thought it was.

Warren

RE: [ECOS] interrupt handlers for the ARM SA1110

[Gary Thomas]

On 23-Jul-2001 Warren Jasper wrote:
> I have a few comments and a suggestion.
> 
> Per Gary Thomas's suggestion, I have added  some hooks to the file
> /hal/arm/sa11x0/var/current/src/sa11x0_misc.c so that I could extend the
> 
> hal_interrupt_handle table to include 32 extra interrupts from my DSP.
> The file
> is attached.   Changes are like:
> 
> /* macro for board specific IRQ handler */
>#ifdef HAL_EXTENDED_IRQ_HANDLER
>       HAL_EXTENDED_IRQ_HANDLER(index);
>  #endif
> 
> Please consider wrapping these changes into the main distribution.
> That way, hooks will be
> available for other variants of the sa11x0  to incorporate extra
> interrupts.
> 
> The user needs to replace
> hal/arm/sa11x0/var/current/include/hal_var_ints.h with
> a modified version:
> hal/arm/sa11x0/variant_board_hal/include/platform_hal_ints.h
> 
> and in the cdl for the variant, include the lines:
> 
>     define_proc {
>         puts $::cdl_header \
>        "#define CYGBLD_HAL_PLF_INTS_H <cyg/hal/hal_platform_ints.h>"
>     }
> 
> Unfortunately, doing this may or may not work.  There is a somewhat
> cryptic comment
> (I guess cryptic comments are better than no comments ???) in
> /hal/arm/arch/current/src/vectors.S  near the end:
> 
> //
> -------------------------------------------------------------------------
> 
> // Interrupt vector tables.
> // These tables contain the isr, data and object pointers used to
> deliver
> // interrupts to user code.
> 
> // Despite appearances, their sizes are not #defines, but .equ symbols
> // generated by magic without proper dependencies in arm.inc
> // Recompiling will not DTRT without manual intervention.
> 
>         .data
> 
> init_flag:
>         .balign 4
>         .long   0
> 
>  .extern hal_default_isr
> 
>  .globl  hal_interrupt_handlers
> hal_interrupt_handlers:
>         .rept   CYGNUM_HAL_ISR_COUNT
>         .long   hal_default_isr
>         .endr
> 
> Once  CYGNUM_HAL_ISR_COUNT is redefined, it sure would be nice to know
> exactly how to
>  increase the size of the table, and to know up front that the following
> wont' work:
> 
> ecosconfig tree
> make clean
> make
> 
> I ended up disassembling the code and counting the size of
> hal_interrupt_handlers before I
> felt confident that that size of the table (which is kind of important)
> was what I thought it was.

As long as you start afresh, the automatic process works fine.  The only
time you would have trouble would be if you changed this constant after
you had built a configuration.  If you didn't do 'make clean' it might
not reserve enough space for the tables.

I'll incorporate your other changes into the mainline CVS sources.