stlink: add arm semi-hosting support

[openocd.git] / doc / openocd.texi

diff --git a/doc/openocd.texi b/doc/openocd.texi
index b56efb8a1e43d5062fb5f1f5bf719ed0ac9e4f2f..4bff7403bc96fa3a41b7b63b1e46857ae441a2b1 100644 (file)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1339,7 +1339,7 @@ have only been used by the developer who created it.
 
 A separate chapter gives information about how to set these up.
 @xref{Debug Adapter Configuration}.
-Read the OpenOCD source code (and Developer's GUide)
+Read the OpenOCD source code (and Developer's Guide)
 if you have a new kind of hardware interface
 and need to provide a driver for it.
 
@@ -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