[ECOS] Re: Questions about vectors.s

[Gary Thomas <gthomas at redhat dot com>]

On Thu, 2001-10-18 at 03:47, Bill Diehls wrote:
> Hi Gary,
> I was wondering if you could answer a few questions
> that my friends and I have.  I posted these on the
> eCos discussion list, but didn't get a response (maybe
> the questions are amateurish -- quite likely :(  We

I've seen this trail - didn't think I needed to get 
involved.

Note: just 'cause I'm a nice guy, I'll answer this direct
query, but only once.  email sent directly to eCos
engineers can and will be ignored.  Please use the list.
We do try and help there, but our time is limited.

> are porting eCos to the Gameboy Advance and we have
> redboot working with console and flash support as well
> as GDB support under redboot.  But we are having some
> problems with the IRQ code in vectors.s.  We are
> getting some stack corruption issues that we have
> spent considerable time tracking down.  At this point
> we plan on working around the issues which entails
> modifying the IRQ code.  We have at least 3 different
> workaround solutions that currently fix the issues,

I'd like to know what these are.

> but we have a few questions that will serve as a
> guide.  I was wondering if you could take second to
> comment on these.  We don't want to unknowingly break
> something that will take days to track down.  Thanks! 
> 
> 
> -- When calling C-code from the IRQ routine (such as
> hal_IRQ_handler) the stack frame (v6) is passed as an
> argument.  Is this for debugging purposes?  Does gdb
> use this?
> 

It was only used for debugging one platform.  In general
it's not used, but keeping in in there is only one instruction.

> -- Toward the end of the IRQ routine (close to the
> switch back to IRQ mode), there are 2 nop
> instructions.  Not that it matters much, but we've
> been curious why they are there.  (On a related note,
> why are the IRQ and FIQ disable bits set separately
> from the mode bits at the end of the IRQ routine?)

Only that this was recommended, at least for early generation
ARM chips.