[ECOS] Gameboy Advance vectors.S (dealing with BIOS)
Mon Jan 21 12:57:00 GMT 2002
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
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
> 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,
> 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.
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
More information about the Ecos-discuss