Re: [ECOS] Gameboy Advance vectors.S (dealing with BIOS)

[Bill Diehls <billabloke at yahoo dot com>]

Hi Jonathan,
Thank you for the suggestions!  Regarding
PLATFORM_VECTORS and (3) (described below), it seems
that PLATFORM_VECTORS is good for inserting code into
vectors.S, but as far as inserting a new section (with
its own absolute address) into arm.ld, another
mechanism is required.  One possibility is to create
PLATFORM_SECTION and insert it into arm.ld such as:

#ifndef PLATFORM_SECTION
#define PLATFORM_SECTION
#endif

#define SECTION_fixed_vectors(_region_, _vma_, _lma_)
\
    .fixed_vectors _vma_ : _lma_ \
    { FORCE_OUTPUT; KEEP (*(.fixed_vectors)) } \
    > _region_ \
    PLATFORM_SECTION

That is, if it wants to be included after
fixed_vectors.  Is there a better way to do this?

thanks,
--bill 


--- Jonathan Larmour <jlarmour@redhat.com> wrote:
> Bill Diehls wrote:
> > 
> > Hello all,
> > Attached is vectors.s that contains the
> modifications
> > for the Gameboy Advance (GBA).  The changes are
> > surrounded by ifdef's (simply search for
> > GAMEBOY_ADVANCE).  There are 11 modifications in
> all.
> > They are listed and described below.  Please offer
> any
> > feedback you may have regarding the best way to
> > integrate these changes into the main source.  I'm
> > assuming that one of the goals is to modify
> vectors.s
> > as little as possible.
> 
> Indeed. Or if a platform has new requirements, try
> to determine what the
> real underlying requirements either and abstracting
> that, rather than just
> #ifdef $port :-).
> 
> > 1) This is a Nintendo requirement where a
> predefined
> > header must be written at the beginning of ROM
> space.
> > This area is filled with zeros to allocate the
> area
> > and is later modified with the correct data which
> > includes checksums, etc.  There is probably a
> cleaner
> > way to do this :)
> 
> Indeed. I was thinking of pointing out
> PLATFORM_PREAMBLE to you. But
> actually I think the best approach is to add a new
> section, something like
> .gbavectors in the PLATFORM_VECTORS hook. Using the
> linker script, you can
> then ensure this is placed at the start of the
> image.
>  
> > 2) Since BIOS exists where the vectors section
> wants
> > to go, this is commented out.  That is, BIOS
> contains
> > its own exception table.  As an alternative I
> could
> > simply tell the linker to put this somewhere out
> of
> > reach and move the modification to the linker
> > script(?)
> 
> That would be better. You probably have to
> explicitly tell the linker to
> discard the section admittedly, but there's examples
> of how to do this
> around (using /DISCARD/).
>  
> > 3) patch_vectors is used to "patch through" the
> > illegal instruction trap used for debugging.  That
> is,
> > BIOS gets the original illegal instruction trap,
> but a
> > certain bit set in the ROM header will instruct
> BIOS
> > to call code at 0x9ffc000 before returning from
> the
> > exception.  Thus, patch_vectors is put in its own
> > section residing at 0x9ffc000.  This code can be
> put
> > in a separate file.  This alludes to a
> modification in
> > arm.ld -- what is the best way to add a section in
> > this way?  Putting ifdef's in arm.ld is probably
> not a
> > good idea either :)
> 
> Again, that's another section you can define from
> the PLATFORM_VECTORS
> hook.
> 
> > 4) This skips exception vector related code that
> is
> > not necessary for the GBA.  I'm not sure if this
> > breaks anything if it is included, however.
> 
> The best thing is to define a new macro that only
> the GBA
> hal_platform_setup.h would define, and
> conditionalize the code on that,
> e.g.
> 
> #ifndef CYG_HAL_ARM_PLATFORM_OWNS_EXCEPTIONS
> 
> > 5) Same reason as 4.  4 and 5 could not be combied
> due
> > to preprocessor matching of #if's and #endif's.
> 
> Yep, ditto answer for 4.
>  
> > 6) This loads the IRQ address into a BIOS register
> and
> > allows the IRQ routine to be called.  This should
> go
> > in hal_hardware_init() I believe.
> > 
> > 7) Related to 6.
> 
> Yes and yes.
>  
> > 8) This had us scratching our heads for quite
> awhile!
> > Since exceptions go through BIOS, which saves some
> > registers to the stack, not restoring the stack
> upon
> > exit will cause BIOS to save registers to the
> wrong
> > memory -- typically corrupting the supervisor
> stack.
> 
> Interesting one. But for a start, not all vectors
> use
> __undef_exception_stack for their stack. Are you
> sure this is the right
> fix? Perhaps it might be better to have a small
> function that is what the
> exception (or BIOS call) will initially go to, that
> saves things so that
> call_exception_handler can run unmodified?
> 
> > 9) This is required to restore registers that get
> > saved at the beginning of the BIOS exception
> routine.
> > This can be moved somewhere else.
> 
> Perhaps what I suggest for 8, would therefore
> provide the location for this
> to be moved to too?
>  
> > 10) Same reason as 8.
> 
> Same potential solution.
>  
> > 11) Related to 3.
> 
> Yep, so won't be needed in vectors.S if it moves
> elsewhere.
> 
> 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


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/