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

[Jonathan Larmour <jlarmour at redhat dot com>]

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