From 7d48be5bd3705b8771f49427824bb421ebf9677e Mon Sep 17 00:00:00 2001 From: Freddie Chopin Date: Thu, 9 Feb 2012 18:37:05 +0100 Subject: [PATCH 1/1] Add init_board documentation This patch adds init_board concept information to OpenOCD manual. Additionally a link from init_targets chapter to new chapter about init_board is added. Change-Id: I09b9aaa1cf68b94f35701224f641cae9811a5bcf Signed-off-by: Freddie Chopin Reviewed-on: http://openocd.zylin.com/440 Tested-by: jenkins Reviewed-by: Spencer Oliver --- doc/openocd.texi | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/doc/openocd.texi b/doc/openocd.texi index 3519222b5c..b56efb8a1e 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -1549,6 +1549,47 @@ also supports it. Otherwise use @command{adapter_khz}. Set the slow rate at the beginning of the reset sequence, and the faster rate as soon as the clocks are at full speed. +@anchor{The init_board procedure} +@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 +@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 +target config file uses @code{init_targets} scheme (``linear'' script is executed before @code{init} and +@code{init_targets} - after), so separating these two configuration stages is very convenient, as the easiest way to +overcome this problem is to convert board config file to use @code{init_board} procedure. Board config scripts don't +need to override @code{init_targets} defined in target config files when they only need to to add some specifics. + +Just as @code{init_targets}, the @code{init_board} procedure can be overriden by ``next level'' script (which sources +the original), allowing greater code reuse. + +@example +### board_file.cfg ### + +# source target file that does most of the config in init_targets +source [find target/target.cfg] + +proc enable_fast_clock @{@} @{ + # enables fast on-board clock source + # configures the chip to use it +@} + +# initialize only board specifics - reset, clock, adapter frequency +proc init_board @{@} @{ + reset_config trst_and_srst trst_pulls_srst + + $_TARGETNAME configure -event reset-init @{ + adapter_khz 1 + enable_fast_clock + adapter_khz 10000 + @} +@} +@end example + @section Target Config Files @cindex config file, target @cindex target config file @@ -1849,6 +1890,8 @@ 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}). + @subsection ARM Core Specific Hacks If the chip has a DCC, enable it. If the chip is an ARM9 with some -- 2.30.2