[uClinux-dev] RFC: Proper way to remap the interrupt vector table?
Brandon Fosdick
brandon at teslamotors.com
Fri Jan 12 13:36:28 EST 2007
I finally have a dist-test kernel booting on an LPC2294. The big show
stopper was the interrupt vector table.
Currently function trap_init() in arch/arm/kernel/traps.c memcpy's the
interrupt vector table to address 0x00. Now, of course, on the LPC22xx
this is only possible if the vector table is remapped outside the
address space of the internal flash (which starts at 0x00). This causes
two problems...
1. The remapped vector space is only 64 bytes long and trap_init() is
trying to copy stub functions (and some other stuff) that overflow the
remapped space.
2. The branch instructions used in the vector table only have a range of
+/- 32MB. Not nearly enough to get from 0x00 into either of the writable
address spaces (>1GB or >2GB).
My kludge-solution uses #ifdef CONFIG_CPU_LPC22xx...
1. in arch/arm/kernel/entry-armv.S to modify the vector table to use
ldr's to jump to the vector handlers directly, bypassing the stubs.
2. in arch/arm/kernel/traps.c to modify trap_init() to not copy the now
useless extra stuff (stubs, etc) that overflows the remapped space.
This seems a bit hacky to me. Can anyone think of a cleaner way to
handle this? Maybe make it conditional on CONFIG_REMAP_VECTORS_TO_RAM?
Actually, I can't think of a reason to need the current table+stub
setup, and the ldr jumps work in all cases. Would it be acceptable to
just drop the stubs altogether?
Incidentally, the LPC2292/2294 can remap the vector table to two
different places, but the current Kconfig setup doesn't handle that very
well. Currently it's assumed that remapping puts the table at 2GB, but
in my case it needs to be at 1GB. Any thoughts?
I'll have patches for all of this once I get the aesthetics worked out.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
More information about the uClinux-dev
mailing list