[ECOS] Re: Questions about vectors.s

[Gary Thomas <gthomas at redhat dot com>]

Copy the ecos-discuss list please!  even if I ask for specific
information, I must insist that this dialog be shared with all.

On Fri, 2001-10-19 at 02:40, Bill Diehls wrote:
> Hi Gary,
> Thank you for the reply!  You asked about the
> workaround solutions we are considering for vectors.s.
>  We are having problems with stack corruption, which
> is somewhat of a mystery.  These two messages describe
> the issue in detail:
> 
> http://sources.redhat.com/ml/ecos-discuss/2001-10/msg00196.html
> http://sources.redhat.com/ml/ecos-discuss/2001-10/msg00352.html
> 
> Anyway, regarding the workarounds, below are some
> solutions that have been tested extensively and have
> been verified:  
> 
> -- Increase ARMREG_SIZE (to 256 for example).  This is
> an easy solution, but it really grows the stack.  And
> since the source of the stack corruption is not fully
> understood, it is not guaranteed that "256" is
> adequate.   

This is clearly wrong.  The value of ARMREG_SIZE is calculated to
be exactly the size of the saved state frame on the stack.  Changing
it is just masking whatever other problem you are having.
 
> -- Stay in IRQ mode.  That is, never switch into
> supervisor mode in the IRQ routine.  This keeps the
> stacks (supervisor and IRQ) separate, but the IRQ
> stack size should probably be increased.

While this might work in some cases, it is also not correct.
Depending on how the eCos kernel is configured, it's actually
possible to switch threads in this piece of code.  If the
IRQ handler is running in IRQ mode, that code will definitely
fail.  It also breaks the basic model that all code inside
the eCos kernel+application run in Supervisor mode.

> -- When switching to supervisor mode, use a new stack,
> and restore the old stack before mode switching back
> to IRQ mode.  This is a variation on the 2nd solution.
>  It allows the IRQ routine to execute in supervisor
> mode as originally designed, but it is unclear that
> this accomplishes anything. 
> 
> It has been entertained (but not verified) that the
> Gameboy has an ARM core tweak, or something hardware
> related that is causing this behavior. 
> 
> Note also, the Gameboy Advance has a ROM "BIOS" that
> we have disassembled, but we cannot modify.  It
> dictates the exception vectors, but provides secondary
> vectors the user can modify.  This has obviously
> resulted in some modifications of vectors.s.  
> 

Can you provide more information here?  My guess is that
the interaction between this BIOS code and the eCos handlers
is where the problem lies.  If you can show me that code,
I might be able to see something.

> Regarding code integration, it appears that it might
> be cleaner to provide an entirely separate vectors.s
> for the Gameboy instead of polluting the existing
> vectors.s with messy preprocessor directives and
> Gameboy specific code.  Your opinion is obviously
> important here.  
> 

Without seeing what you've had to change, I can't comment.

> best regards,
> --Bill, Rich, Garrick
>   
> --- Gary Thomas <gthomas@redhat.com> wrote:
> > 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.
> > 
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com