[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