zcy
/
tinyriscv-openocd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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 <freddie.chopin@gmail.com>
Reviewed-on: http://openocd.zylin.com/440
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
__archive__
Freddie Chopin 2012-02-09 18:37:05 +01:00 committed by Spencer Oliver
parent 5bcb78f181
commit 7d48be5bd3
1 changed files with 43 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
doc/openocd.texi
View File

@ -1549,6 +1549,47 @@ also supports it. Otherwise use @command{adapter_khz}.
Set the slow rate at the beginning of the reset sequence, Set the slow rate at the beginning of the reset sequence,
and the faster rate as soon as the clocks are at full speed. 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 @section Target Config Files
@cindex config file, target @cindex config file, target
@cindex target config file @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. 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 @subsection ARM Core Specific Hacks
If the chip has a DCC, enable it. If the chip is an ARM9 with some If the chip has a DCC, enable it. If the chip is an ARM9 with some