diff options
author | Mike Dunn <mikedunn@newsguy.com> | 2010-08-02 12:50:29 -0700 |
---|---|---|
committer | Øyvind Harboe <oyvind.harboe@zylin.com> | 2010-08-02 22:39:48 +0200 |
commit | 7682877c8ca59226f7131db5fe35253acf117bb4 (patch) | |
tree | 5db8570a570953a8d28530319119b2b92c379dc0 | |
parent | bfa34f88f8b77596d6f70be446708a3f5a604e9b (diff) | |
download | riscv-openocd-7682877c8ca59226f7131db5fe35253acf117bb4.zip riscv-openocd-7682877c8ca59226f7131db5fe35253acf117bb4.tar.gz riscv-openocd-7682877c8ca59226f7131db5fe35253acf117bb4.tar.bz2 |
xscale documentation: vector table handling
Hi everyone. I noticed some incorrect information in the user manual
regarding how the vector table is handled on the xscale, so for your
consideration, here's a short patch that corrects it, and adds a
little more detail I thought might be helpful.
The documentation states that OpenOCD does not attempt to synchronize
the vector tables in memory with those stored in the "mini instruction
cache". In fact, on each resume it does copy from memory to the cache
all entries in the high and low tables that were not previously
defined using the 'xscale vector_table' command. (In
src/target/xscale.c, see xscale_update_vectors(), which is invoked by
xscale_resume().) I take advantage of this during Linux boot-up. The
extra detail describes in general terms how I do this.
Corrections, comments are of course gratefully received.
Thanks,
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
-rw-r--r-- | doc/openocd.texi | 26 |
1 files changed, 22 insertions, 4 deletions
diff --git a/doc/openocd.texi b/doc/openocd.texi index 97d2e81..0e57c1a 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -6337,10 +6337,10 @@ handler. However, this means that the complete first cacheline in the mini-IC is marked valid, which makes the CPU fetch all exception handlers from the mini-IC, ignoring the code in RAM. -OpenOCD currently does not sync the mini-IC entries with the RAM -contents (which would fail anyway while the target is running), so -the user must provide appropriate values using the @code{xscale -vector_table} command. +To address this situation, OpenOCD provides the @code{xscale +vector_table} command, which allows the user to explicity write +individual entries to either the high or low vector table stored in +the mini-IC. It is recommended to place a pc-relative indirect branch in the vector table, and put the branch destination somewhere in memory. Doing so @@ -6367,6 +6367,24 @@ _vectors: .long real_fiq_handler @end example +Alternatively, you may choose to keep some or all of the mini-IC +vector table entries synced with those written to memory by your +system software. The mini-IC can not be modified while the processor +is executing, but for each vector table entry not previously defined +using the @code{xscale vector_table} command, OpenOCD will copy the +value from memory to the mini-IC every time execution resumes from a +halt. This is done for both high and low vector tables (although the +table not in use may not be mapped to valid memory, and in this case +that copy operation will silently fail). This means that you will +need to briefly halt execution at some strategic point during system +start-up; e.g., after the software has initialized the vector table, +but before exceptions are enabled. A breakpoint can be used to +accomplish this once the appropriate location in the start-up code has +been identified. A watchpoint over the vector table region is helpful +in finding the location if you're not sure. Note that the same +situation exists any time the vector table is modified by the system +software. + The debug handler must be placed somewhere in the address space using the @code{xscale debug_handler} command. The allowed locations for the debug handler are either (0x800 - 0x1fef800) or (0xfe000800 - |