interesting
/
riscv-openocd
mirror of https://github.com/riscv/riscv-openocd.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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>
This commit is contained in:
Mike Dunn 2010-08-02 12:50:29 -07:00 committed by Øyvind Harboe
parent bfa34f88f8
commit 7682877c8c
1 changed files with 22 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
doc/openocd.texi
View File

@ -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 -