Add value "openbsd" for ocd_HOSTOS.

[fw/openocd] / doc / openocd.texi

diff --git a/doc/openocd.texi b/doc/openocd.texi
index 97562509886c0b202b01ec59614b09e3f5be4041..71605ecea39fb88e3e5ee6e4b741c0c0bf3ac72b 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.
@@ -4654,13 +4654,6 @@ The AVR 8-bit microcontrollers from Atmel integrate flash memory.
 @comment - defines mass_erase ... pointless given flash_erase_address
 @end deffn
 
-@deffn {Flash Driver} ecosflash
-@emph{No idea what this is...}
-The @var{ecosflash} driver defines one mandatory parameter,
-the name of a modules of target code which is downloaded
-and executed.
-@end deffn
-
 @deffn {Flash Driver} lpc2000
 Most members of the LPC1700 and LPC2000 microcontroller families from NXP
 include internal flash and use Cortex-M3 (LPC1700) or ARM7TDMI (LPC2000) cores.
@@ -4912,6 +4905,12 @@ the chip identification register, and autoconfigures itself.
 flash bank $_FLASHNAME stm32f1x 0 0 0 0 $_TARGETNAME
 @end example
 
+If you have a target with dual flash banks then define the second bank
+as per the following example.
+@example
+flash bank $_FLASHNAME stm32f1x 0x08080000 0 0 0 $_TARGETNAME
+@end example
+
 Some stm32f1x-specific commands
 @footnote{Currently there is a @command{stm32f1x mass_erase} command.
 That seems pointless since the same effect can be had using the