+@enumerate
+@item A small openocd.cfg file which ``sources'' other configuration files
+@item A monolithic openocd.cfg file
+@item Many -f filename options on the command line
+@item Your Mixed Solution
+@end enumerate
+
+@section Small configuration file method
+
+This is the prefered method, it is simple and is works well for many
+people. The developers of OpenOCD would encourage you to use this
+method. If you create a new configuration please email new
+configurations to the development list.
+
+Here is an example of an openocd.cfg file for an ATMEL at91sam7x256
+
+@example
+source [find interface/signalyzer.cfg]
+
+# Change the default telnet port...
+telnet_port 4444
+# GDB connects here
+gdb_port 3333
+# GDB can also flash my flash!
+gdb_memory_map enable
+gdb_flash_program enable
+
+source [find target/sam7x256.cfg]
+@end example
+
+There are many example configuration scripts you can work with. You
+should look in the directory: @t{$(INSTALLDIR)/lib/openocd}. You
+should find:
+
+@enumerate
+@item @b{board} - eval board level configurations
+@item @b{interface} - specific dongle configurations
+@item @b{target} - the target chips
+@item @b{tcl} - helper scripts
+@item @b{xscale} - things specific to the xscale.
+@end enumerate
+
+Look first in the ``boards'' area, then the ``targets'' area. Often a board
+configuration is a good example to work from.
+
+@section Many -f filename options
+Some believe this is a wonderful solution, others find it painful.
+
+You can use a series of ``-f filename'' options on the command line,
+OpenOCD will read each filename in sequence, for example:
+
+@example
+ openocd -f file1.cfg -f file2.cfg -f file2.cfg
+@end example
+
+You can also intermix various commands with the ``-c'' command line
+option.
+
+@section Monolithic file
+The ``Monolithic File'' dispenses with all ``source'' statements and
+puts everything in one self contained (monolithic) file. This is not
+encouraged.
+
+Please try to ``source'' various files or use the multiple -f
+technique.
+
+@section Advice for you
+Often, one uses a ``mixed approach''. Where possible, please try to
+``source'' common things, and if needed cut/paste parts of the
+standard distribution configuration files as needed.
+
+@b{REMEMBER:} The ``important parts'' of your configuration file are:
+
+@enumerate
+@item @b{Interface} - Defines the dongle
+@item @b{Taps} - Defines the JTAG Taps
+@item @b{GDB Targets} - What GDB talks to
+@item @b{Flash Programing} - Very Helpful
+@end enumerate
+
+Some key things you should look at and understand are:
+
+@enumerate
+@item The RESET configuration of your debug environment as a hole
+@item Is there a ``work area'' that OpenOCD can use?
+@* For ARM - work areas mean up to 10x faster downloads.
+@item For MMU/MPU based ARM chips (ie: ARM9 and later) will that work area still be available?
+@item For complex targets (multiple chips) the JTAG SPEED becomes an issue.
+@end enumerate
+
+
+
+@node Config File Guidelines
+@chapter Config File Guidelines
+
+This section/chapter is aimed at developers and integrators of
+OpenOCD. These are guidelines for creating new boards and new target
+configurations as of 28/Nov/2008.
+
+However, you the user of OpenOCD should be some what familiar with
+this section as it should help explain some of the internals of what
+you might be looking at.
+
+The user should find under @t{$(INSTALLDIR)/lib/openocd} the
+following directories:
+
+@itemize @bullet
+@item @b{interface}
+@*Think JTAG Dongle. Files that configure the jtag dongle go here.
+@item @b{board}
+@* Thing Circuit Board, PWA, PCB, they go by many names. Board files
+contain initialization items that are specific to a board - for
+example: The SDRAM initialization sequence for the board, or the type
+of external flash and what address it is found at. Any initialization
+sequence to enable that external flash or sdram should be found in the
+board file. Boards may also contain multiple targets, ie: Two cpus, or
+a CPU and an FPGA or CPLD.
+@item @b{target}
+@* Think CHIP. The ``target'' directory represents a jtag tap (or
+chip) OpenOCD should control, not a board. Two common types of targets
+are ARM chips and FPGA or CPLD chips.
+@end itemize
+
+@b{If needed...} The user in their ``openocd.cfg'' file or the board
+file might override a specific feature in any of the above files by
+setting a variable or two before sourcing the target file. Or adding
+various commands specific to their situation.
+
+@section Interface Config Files
+
+The user should be able to source one of these files via a command like this:
+
+@example
+ source [find interface/FOOBAR.cfg]
+Or:
+ openocd -f interface/FOOBAR.cfg
+@end example
+
+A preconfigured interface file should exist for every interface in use
+today, that said, perhaps some interfaces have only been used by the
+sole developer who created it.
+
+@b{FIXME/NOTE:} We need to add support for a variable like TCL variable
+tcl_platform(platform), it should be called jim_platform (because it
+is jim, not real tcl) and it should contain 1 of 3 words: ``linux'',
+``cygwin'' or ``mingw''
+
+Interface files should be found in @t{$(INSTALLDIR)/lib/openocd/interface}
+
+@section Board Config Files
+
+@b{Note: BOARD directory NEW as of 28/nov/2008}
+
+The user should be able to source one of these files via a command like this:
+
+@example
+ source [find board/FOOBAR.cfg]
+Or:
+ openocd -f board/FOOBAR.cfg
+@end example
+
+
+The board file should contain one or more @t{source [find
+target/FOO.cfg]} statements along with any board specific things.
+
+In summery the board files should contain (if present)
+
+@enumerate
+@item External flash configuration (ie: the flash on CS0)
+@item SDRAM configuration (size, speed, etc)
+@item Board specific IO configuration (ie: GPIO pins might disable a 2nd flash)
+@item Multiple TARGET source statements
+@item All things that are not ``inside a chip''
+@item Things inside a chip go in a 'target' file
+@end enumerate
+
+@section Target Config Files
+
+The user should be able to source one of these files via a command like this:
+
+@example
+ source [find target/FOOBAR.cfg]
+Or:
+ openocd -f target/FOOBAR.cfg
+@end example
+
+In summery the target files should contain
+
+@enumerate
+@item Set Defaults
+@item Create Taps
+@item Reset Configuration
+@item Work Areas
+@item CPU/Chip/CPU-Core Specific features
+@item OnChip Flash
+@end enumerate
+
+@subsection Important variable names
+
+By default, the end user should never need to set these
+variables. However, if the user needs to override a setting they only
+need to set the variable in a simple way.
+
+@itemize @bullet
+@item @b{CHIPNAME}
+@* This gives a name to the overall chip, and is used as part of the
+tap identifier dotted name.
+@item @b{ENDIAN}
+@* By default little - unless the chip or board is not normally used that way.
+@item @b{CPUTAPID}
+@* When OpenOCD examines the JTAG chain, it will attempt to identify
+every chip. If the @t{-expected-id} is nonzero, OpenOCD attempts
+to verify the tap id number verses configuration file and may issue an
+error or warning like this. The hope is this will help pin point
+problem OpenOCD configurations.
+
+@example
+Info: JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)
+Error: ERROR: Tap: sam7x256.cpu - Expected id: 0x12345678, Got: 0x3f0f0f0f
+Error: ERROR: expected: mfg: 0x33c, part: 0x2345, ver: 0x1
+Error: ERROR: got: mfg: 0x787, part: 0xf0f0, ver: 0x3
+@end example
+
+@item @b{_TARGETNAME}
+@* By convention, this variable is created by the target configuration
+script. The board configuration file may make use of this variable to
+configure things like a ``reset init'' script, or other things
+specific to that board and that target.
+
+If the chip has 2 targets, use the names @b{_TARGETNAME0},
+@b{_TARGETNAME1}, ... etc.
+
+@b{Remember:} The ``board file'' may include multiple targets.
+
+At no time should the name ``target0'' (the default target name if
+none was specified) be used. The name ``target0'' is a hard coded name
+- the next target on the board will be some other number.
+
+The user (or board file) should reasonably be able to:
+
+@example
+ source [find target/FOO.cfg]
+ $_TARGETNAME configure ... FOO specific parameters
+
+ source [find target/BAR.cfg]
+ $_TARGETNAME configure ... BAR specific parameters
+@end example
+
+@end itemize
+
+@subsection TCL Variables Guide Line
+The Full Tcl/Tk language supports ``namespaces'' - JIM-Tcl does not.
+
+Thus the rule we follow in OpenOCD is this: Variables that begin with
+a leading underscore are temporal in nature, and can be modified and
+used at will within a ?TARGET? configuration file
+
+@b{EXAMPLE:} The user should be able to do this:
+
+@example
+ # Board has 3 chips,
+ # PXA270 #1 network side, big endian
+ # PXA270 #2 video side, little endian
+ # Xilinx Glue logic
+ set CHIPNAME network
+ set ENDIAN big
+ source [find target/pxa270.cfg]
+ # variable: _TARGETNAME = network.cpu
+ # other commands can refer to the "network.cpu" tap.
+ $_TARGETNAME configure .... params for this cpu..
+
+ set ENDIAN little
+ set CHIPNAME video
+ source [find target/pxa270.cfg]
+ # variable: _TARGETNAME = video.cpu
+ # other commands can refer to the "video.cpu" tap.
+ $_TARGETNAME configure .... params for this cpu..
+
+ unset ENDIAN
+ set CHIPNAME xilinx
+ source [find target/spartan3.cfg]
+
+ # Since $_TARGETNAME is temporal..
+ # these names still work!
+ network.cpu configure ... params
+ video.cpu configure ... params
+
+@end example
+
+@subsection Default Value Boiler Plate Code
+
+All target configuration files should start with this (or a modified form)
+
+@example
+# SIMPLE example
+if @{ [info exists CHIPNAME] @} @{
+ set _CHIPNAME $CHIPNAME
+@} else @{
+ set _CHIPNAME sam7x256
+@}
+
+if @{ [info exists ENDIAN] @} @{
+ set _ENDIAN $ENDIAN
+@} else @{
+ set _ENDIAN little
+@}
+
+if @{ [info exists CPUTAPID ] @} @{
+ set _CPUTAPID $CPUTAPID
+@} else @{
+ set _CPUTAPID 0x3f0f0f0f
+@}
+
+@end example
+
+@subsection Creating Taps
+After the ``defaults'' are choosen, [see above], the taps are created.
+
+@b{SIMPLE example:} such as an Atmel AT91SAM7X256
+
+@example
+# for an ARM7TDMI.
+set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
+@end example
+
+@b{COMPLEX example:}
+
+This is an SNIP/example for an STR912 - which has 3 internal taps. Key features shown:
+
+@enumerate
+@item @b{Unform tap names} - See: Tap Naming Convention
+@item @b{_TARGETNAME} is created at the end where used.
+@end enumerate
+
+@example
+if @{ [info exists FLASHTAPID ] @} @{
+ set _FLASHTAPID $FLASHTAPID
+@} else @{
+ set _FLASHTAPID 0x25966041
+@}
+jtag newtap $_CHIPNAME flash -irlen 8 -ircapture 0x1 -irmask 0x1 -expected-id $_FLASHTAPID
+
+if @{ [info exists CPUTAPID ] @} @{
+ set _CPUTAPID $CPUTAPID
+@} else @{
+ set _CPUTAPID 0x25966041
+@}
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0xf -irmask 0xe -expected-id $_CPUTAPID
+
+
+if @{ [info exists BSTAPID ] @} @{
+ set _BSTAPID $BSTAPID
+@} else @{
+ set _BSTAPID 0x1457f041
+@}
+jtag newtap $_CHIPNAME bs -irlen 5 -ircapture 0x1 -irmask 0x1 -expected-id $_BSTAPID
+
+set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
+@end example
+
+@b{Tap Naming Convention}
+
+See the command ``jtag newtap'' for detail, but in breif the names you should use are:
+
+@itemize @bullet
+@item @b{tap}
+@item @b{cpu}
+@item @b{flash}
+@item @b{bs}
+@item @b{jrc}
+@item @b{unknownN} - it happens :-(
+@end itemize
+
+@subsection Reset Configuration
+
+Some chips have specific ways the TRST and SRST signals are
+managed. If these are @b{CHIP SPECIFIC} they go here, if they are
+@b{BOARD SPECIFIC} they go in the board file.
+
+@subsection Work Areas
+
+Work areas are small RAM areas used by OpenOCD to speed up downloads,
+and to download small snippits of code to program flash chips.
+
+If the chip includes an form of ``on-chip-ram'' - and many do - define
+a reasonable work area and use the ``backup'' option.
+
+@b{PROBLEMS:} On more complex chips, this ``work area'' may become
+inaccessable if/when the application code enables or disables the MMU.
+
+@subsection ARM Core Specific Hacks
+
+If the chip has a DCC, enable it. If the chip is an arm9 with some
+special high speed download - enable it.
+
+If the chip has an ARM ``vector catch'' feature - by defeault enable
+it for Undefined Instructions, Data Abort, and Prefetch Abort, if the
+user is really writing a handler for those situations - they can
+easily disable it. Experiance has shown the ``vector catch'' is
+helpful - for common programing errors.
+
+If present, the MMU, the MPU and the CACHE should be disabled.
+
+@subsection Internal Flash Configuration
+
+This applies @b{ONLY TO MICROCONTROLLERS} that have flash built in.
+
+@b{Never ever} in the ``target configuration file'' define any type of
+flash that is external to the chip. (For example the BOOT flash on
+Chip Select 0). The BOOT flash information goes in a board file - not
+the TARGET (chip) file.
+
+Examples:
+@itemize @bullet
+@item at91sam7x256 - has 256K flash YES enable it.
+@item str912 - has flash internal YES enable it.
+@item imx27 - uses boot flash on CS0 - it goes in the board file.
+@item pxa270 - again - CS0 flash - it goes in the board file.
+@end itemize
+
+@node About JIM-Tcl
+@chapter About JIM-Tcl
+@cindex JIM Tcl
+@cindex tcl
+
+OpenOCD includes a small ``TCL Interpreter'' known as JIM-TCL. You can
+learn more about JIM here: @url{http://jim.berlios.de}