diff --git a/doc/openocd.texi b/doc/openocd.texi
index 975625098..4bff7403b 100644
--- 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