aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorMike 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
commit7682877c8ca59226f7131db5fe35253acf117bb4 (patch)
tree5db8570a570953a8d28530319119b2b92c379dc0 /doc
parentbfa34f88f8b77596d6f70be446708a3f5a604e9b (diff)
downloadriscv-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>
Diffstat (limited to 'doc')
-rw-r--r--doc/openocd.texi26
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 -