Revert "stlink-v1: fix memory writes"

[openocd.git] / doc / openocd.texi

diff --git a/doc/openocd.texi b/doc/openocd.texi
index 97562509886c0b202b01ec59614b09e3f5be4041..323136f373813f7bf447fa79fca893ae7a3fdf88 100644 (file)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1553,9 +1553,9 @@ and the faster rate as soon as the clocks are at full speed.
 @subsection The init_board procedure
 @cindex init_board procedure
 
-The concept of @code{init_board} procedure is very similar to @code{init_targets} (@xref{The init_targets procedure}) -
-it's a replacement of ``linear'' configuration scripts. This procedure is meant to be executed when OpenOCD enters run
-stage (@xref{Entering the Run Stage}), after @code{init_targets}. The idea to have spearate @code{init_targets} and
+The concept of @code{init_board} procedure is very similar to @code{init_targets} (@xref{The init_targets procedure}.)
+- it's a replacement of ``linear'' configuration scripts. This procedure is meant to be executed when OpenOCD enters run
+stage (@xref{Entering the Run Stage},) after @code{init_targets}. The idea to have spearate @code{init_targets} and
 @code{init_board} procedures is to allow the first one to configure everything target specific (internal flash,
 internal RAM, etc.) and the second one to configure everything board specific (reset signals, chip frequency,
 reset-init event handler, external memory, etc.). Additionally ``linear'' board config file will most likely fail when
@@ -1856,8 +1856,8 @@ look at how you are setting up JTAG clocking.
 @cindex init_targets procedure
 
 Target config files can either be ``linear'' (script executed line-by-line when parsed in configuration stage,
-@xref{Configuration Stage}) or they can contain a special procedure called @code{init_targets}, which will be executed
-when entering run stage (after parsing all config files or after @code{init} command, @xref{Entering the Run Stage}).
+@xref{Configuration Stage},) or they can contain a special procedure called @code{init_targets}, which will be executed
+when entering run stage (after parsing all config files or after @code{init} command, @xref{Entering the Run Stage}.)
 Such procedure can be overriden by ``next level'' script (which sources the original). This concept faciliates code
 reuse when basic target config files provide generic configuration procedures and @code{init_targets} procedure, which
 can then be sourced and enchanced or changed in a ``more specific'' target config file. This is not possible with
@@ -1890,7 +1890,7 @@ The easiest way to convert ``linear'' config files to @code{init_targets} versio
 
 For an example of this scheme see LPC2000 target config files.
 
-The @code{init_boards} procedure is a similar concept concerning board config files (@xref{The init_board procedure}).
+The @code{init_boards} procedure is a similar concept concerning board config files (@xref{The init_board procedure}.)
 
 @subsection ARM Core Specific Hacks
 
@@ -3369,7 +3369,7 @@ hardware to find these values.
 option.  When vendors put out multiple versions of a chip, or use the same
 JTAG-level ID for several largely-compatible chips, it may be more practical
 to ignore the version field than to update config files to handle all of
-the various chip IDs.
+the various chip IDs. The version field is defined as bit 28-31 of the IDCODE.
 @item @code{-ircapture} @var{NUMBER}
 @*The bit pattern loaded by the TAP into the JTAG shift register
 on entry to the @sc{ircapture} state, such as 0x01.