[Openocd-svn] r2013 - trunk/doc

[<zw...@ma...>]

Author: zwelch
Date: 2009-06-03 02:56:50 +0200 (Wed, 03 Jun 2009)
New Revision: 2013

Modified:
   trunk/doc/openocd.texi
Log:
David Brownell <da...@pa...>:

Rework the TAP creation documentation.

 - Try to use "TAP" not "tap" everywhere; it's an acronym.

 - Update the associated "target config files" section:
     * reference the "TAP Creation" chapter for details
     * simplify:  reference interesting multi-tap config files
     * let's not forget CPU configuration (*before* workspace setup)
     * streamline it a bit
     * move that workspace-vs-mmu issue to a better location

 - Clean up TAP creation doc mess
     * switch to @deffn
     * (re)organize the remaining stuff
     * reference the "Config File Guidelines" chapter

 - Tweak the "Target Configuration" chapter
     * rename as "CPU configuration"; unconfuse vs. target/*.cfg
     * bring out that it's not just there for GDB
     * move TAP events to the TAP chapter, where they belong (bugfix)


Modified: trunk/doc/openocd.texi
===================================================================
--- trunk/doc/openocd.texi	2009-06-03 00:45:21 UTC (rev 2012)
+++ trunk/doc/openocd.texi	2009-06-03 00:56:50 UTC (rev 2013)
@@ -69,8 +69,8 @@
 * Daemon Configuration::             Daemon Configuration
 * Interface - Dongle Configuration:: Interface - Dongle Configuration
 * Reset Configuration::              Reset Configuration
-* Tap Creation::                     Tap Creation
-* Target Configuration::             Target Configuration
+* TAP Creation::                     TAP Creation
+* CPU Configuration::                CPU Configuration
 * Flash Commands::                   Flash Commands
 * NAND Flash Commands::              NAND Flash Commands
 * General Commands::                 General Commands
@@ -111,7 +111,10 @@
 devices.
 
 @b{JTAG:} OpenOCD uses a ``hardware interface dongle'' to communicate
-with the JTAG (IEEE 1149.1) compliant taps on your target board.
+with the JTAG (IEEE 1149.1) compliant TAPs on your target board.
+A @dfn{TAP} is a ``Test Access Port'', a module which processes
+special instructions and data.  TAPs are daisy-chained within and
+between chips and boards.
 
 @b{Dongles:} OpenOCD currently supports many types of hardware dongles: USB
 based, parallel port based, and other standalone boxes that run
@@ -835,9 +838,12 @@
 board file. Boards may also contain multiple targets, i.e.: 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
+@* Think chip. The ``target'' directory represents the JTAG TAPs
+on a chip
+which OpenOCD should control, not a board. Two common types of targets
 are ARM chips and FPGA or CPLD chips.
+When a chip has multiple TAPs (maybe it has both ARM and DSP cores),
+the target config file defines all of them.
 @end itemize
 
 @b{If needed...} The user in their ``openocd.cfg'' file or the board
@@ -902,9 +908,9 @@
 
 @enumerate 
 @item Set defaults
-@item Create taps
+@item Add TAPs to the scan chain
+@item Add CPU targets
 @item Reset configuration
-@item Work areas
 @item CPU/Chip/CPU-Core specific features
 @item On-Chip flash
 @end enumerate
@@ -1002,7 +1008,6 @@
    #  these names still work!
    network.cpu configure ... params
    video.cpu   configure ... params
-
 @end example
 
 @subsection Default Value Boiler Plate Code
@@ -1028,90 +1033,69 @@
 @} else @{
    set _CPUTAPID 0x3f0f0f0f
 @}
-
 @end example
 
-@subsection Creating Taps
-After the ``defaults'' are choosen [see above] the taps are created.
+@subsection Adding TAPs to the Scan Chain
+After the ``defaults'' are set up,
+add the TAPs on each chip to the JTAG scan chain.
+@xref{TAP Creation}, and the naming convention
+for taps.
 
-@b{SIMPLE example:} such as an Atmel AT91SAM7X256
+In the simplest case the chip has only one TAP,
+probably for a CPU or FPGA.
+The config file for the Atmel AT91SAM7X256
+looks (in part) like this:
 
 @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:}
+A board with two such at91sam7 chips would be able
+to source such a config file twice, with different
+values for @code{CHIPNAME} and @code{CPUTAPID}, so
+it adds a different TAP each time.
 
-This is an SNIP/example for an STR912 - which has 3 internal taps. Key features shown:
+There are more complex examples too, with chips that have
+multiple TAPs.  Ones worth looking at include:
 
-@enumerate
-@item @b{Unform tap names} - See: Tap Naming Convention
-@item @b{_TARGETNAME} is created at the end where used.
-@end enumerate
+@itemize
+@item @file{target/omap3530.cfg} -- with a disabled ARM, and a JRC
+(there's a DSP too, which is not listed)
+@item @file{target/str912.cfg} -- with flash, CPU, and boundary scan
+@item @file{target/ti_dm355.cfg} -- with ETM, ARM, and JRC (this JRC
+is not currently used)
+@end itemize
 
-@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
+@subsection Add CPU targets
 
-if @{ [info exists CPUTAPID ] @} @{
-   set _CPUTAPID $CPUTAPID
-@} else @{
-   set _CPUTAPID 0x25966041
-@}
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0xf -irmask 0xe \
-        -expected-id $_CPUTAPID
+After adding a TAP for a CPU, you should set it up so that
+GDB and other commands can use it.
+@xref{CPU Configuration}.
+For the at91sam7 example above, the command can look like this:
 
+@example
+target create $_TARGETNAME arm7tdmi -chain-position $_TARGETNAME
+@end example
 
-if @{ [info exists BSTAPID ] @} @{
-   set _BSTAPID $BSTAPID
-@} else @{
-   set _BSTAPID 0x1457f041
-@}
-jtag newtap $_CHIPNAME bs -irlen 5 -ircapture 0x1 -irmask 0x1 \
-        -expected-id $_BSTAPID
+Work areas are small RAM areas associated with CPU targets.
+They are used by OpenOCD to speed up downloads,
+and to download small snippets of code to program flash chips.
+If the chip includes a form of ``on-chip-ram'' - and many do - define
+a work area if you can.
+Again using the at91sam7 as an example, this can look like:
 
-set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
+@example
+$_TARGETNAME configure -work-area-phys 0x00200000 \
+	-work-area-size 0x4000 -work-area-backup 0
 @end example
 
-@b{Tap Naming Convention}
-
-See the command ``jtag newtap'' for detail, but in brief the names you should use are:
-
-@itemize @bullet
-@item @b{tap}
-@item @b{cpu}
-@item @b{flash}
-@item @b{bs}
-@item @b{etb}
-@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 snippets of code to program flash chips.
-
-If the chip includes a 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
-inaccessible 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
@@ -1800,209 +1784,274 @@
 @end deffn
 
 
-@node Tap Creation
-@chapter Tap Creation
-@cindex tap creation
-@cindex tap configuration
+@node TAP Creation
+@chapter TAP Creation
+@cindex TAP creation
+@cindex TAP configuration
 
-In order for OpenOCD to control a target, a JTAG tap must be
-defined/created.
+@emph{Test Access Ports} (TAPs) are the core of JTAG.
+TAPs serve many roles, including:
 
-Commands to create taps are normally found in a configuration file and
-are not normally typed by a human.
-
-When a tap is created a @b{dotted.name} is created for the tap. Other
-commands use that dotted.name to manipulate or refer to the tap.
-
-Tap Uses:
 @itemize @bullet
-@item @b{Debug Target} A tap can be used by a GDB debug target
-@item @b{Flash Programing} Some chips program the flash directly via JTAG,
-instead of indirectly by making a CPU do it.
-@item @b{Boundry Scan} Some chips support boundary scan.
+@item @b{Debug Target} A CPU TAP can be used as a GDB debug target
+@item @b{Flash Programing} Some chips program the flash directly via JTAG.
+Others do it indirectly, making a CPU do it.
+@item @b{Program Download} Using the same CPU support GDB uses,
+you can initialize a DRAM controller, download code to DRAM, and then
+start running that code.
+@item @b{Boundary Scan} Most chips support boundary scan, which
+helps test for board assembly problems like solder bridges
+and missing connections
 @end itemize
 
+OpenOCD must know about the active TAPs on your board(s).
+Setting up the TAPs is the core task of your configuration files.
+Once those TAPs are set up, you can pass their names to code
+which sets up CPUs and exports them as GDB targets,
+probes flash memory, performs low-level JTAG operations, and more.
 
-@anchor{jtag newtap}
-@section jtag newtap
-@b{@t{jtag newtap CHIPNAME TAPNAME  configparams ....}}
-@cindex jtag newtap
-@cindex tap
-@cindex tap order
-@cindex tap geometry
+@section Scan Chains
 
-@comment START options
-@itemize @bullet
-@item @b{CHIPNAME}
-@* is a symbolic name of the chip. 
-@item @b{TAPNAME}
-@* is a symbol name of a tap present on the chip.
-@item @b{Required configparams}
-@* Every tap has 3 required configparams, and several ``optional
-parameters'', the required parameters are:
-@comment START REQUIRED
-@itemize @bullet
-@item @b{-irlen NUMBER} - the length in bits of the instruction register, mostly 4 or 5 bits.
-@item @b{-ircapture NUMBER} - the IDCODE capture command, usually 0x01.
-@item @b{-irmask NUMBER} - the corresponding mask for the IR register. For
-some devices, there are bits in the IR that aren't used.  This lets you mask
-them off when doing comparisons.  In general, this should just be all ones for
-the size of the IR.
-@comment END REQUIRED
-@end itemize
-An example of a FOOBAR Tap
+OpenOCD uses a JTAG adapter (interface) to talk to your board,
+which has a daisy chain of TAPs.
+That daisy chain is called a @dfn{scan chain}.
+Simple configurations may have a single TAP in the scan chain,
+perhaps for a microcontroller.
+Complex configurations might have a dozen or more TAPs:
+several in one chip, more in the next, and connecting
+to other boards with their own chips and TAPs.
+
+Unfortunately those TAPs can't always be autoconfigured,
+because not all devices provide good support for that.
+(JTAG doesn't require supporting IDCODE instructions.)
+The configuration mechanism currently supported by OpenOCD
+requires explicit configuration of all TAP devices using
+@command{jtag newtap} commands.
+One like this would create a tap named @code{chip1.cpu}:
+
 @example
-jtag newtap foobar tap -irlen 7 -ircapture 0x42 -irmask 0x55
+jtag newtap chip1 cpu -irlen 7 -ircapture 0x01 -irmask 0x55
 @end example
-Creates the tap ``foobar.tap'' with the instruction register (IR) is 7
-bits long, during Capture-IR 0x42 is loaded into the IR, and bits
-[6,4,2,0] are checked.
 
-@item @b{Optional configparams}
-@comment START Optional
-@itemize @bullet
-@item @b{-expected-id NUMBER}
-@* By default it is zero. If non-zero represents the
-expected tap ID used when the JTAG chain is examined. Repeat 
-the option as many times as required if multiple id's can be
-expected. See below. 
-@item @b{-disable}
-@item @b{-enable}
-@* By default not specified the tap is enabled. Some chips have a
-JTAG route controller (JRC) that is used to enable and/or disable
-specific JTAG taps. You can later enable or disable any JTAG tap via
-the command @b{jtag tapenable DOTTED.NAME} or @b{jtag tapdisable 
-DOTTED.NAME}
-@comment END Optional
-@end itemize
+Each target configuration file lists the TAPs provided
+by a given chip.
+Board configuration files combine all the targets on a board,
+and so forth.
+Note that @emph{the order in which TAPs are created is very important.}
+It must match the order in the JTAG scan chain, both inside
+a single chip and between them.
 
-@comment END OPTIONS
-@end itemize
-@b{Notes:}
-@comment START NOTES
-@itemize @bullet
-@item @b{Technically}
-@* newtap is a sub command of the ``jtag'' command
-@item @b{Big Picture Background}
-@*GDB Talks to OpenOCD using the GDB protocol via
-TCP/IP. OpenOCD then uses the JTAG interface (the dongle) to
-control the JTAG chain on your board. Your board has one or more chips
-in a @i{daisy chain configuration}. Each chip may have one or more
-JTAG taps. GDB ends up talking via OpenOCD to one of the taps.
-@item @b{NAME Rules}
-@*Names follow ``C'' symbol name rules (start with alpha ...)
-@item @b{TAPNAME - Conventions}
-@itemize @bullet
-@item @b{tap} - should be used only FPGA or CPLD like devices with a single tap.
-@item @b{cpu} - the main CPU of the chip, alternatively @b{foo.arm} and @b{foo.dsp}
-@item @b{flash} - if the chip has a flash tap, example: str912.flash
-@item @b{bs} - for boundary scan if this is a seperate tap.
-@item @b{etb} - for an embedded trace buffer (example: an ARM ETB11)
-@item @b{jrc} - for JTAG route controller (example: OMAP3530 found on Beagleboards)
-@item @b{unknownN} - where N is a number if you have no idea what the tap is for
-@item @b{Other names} - Freescale IMX31 has a SDMA (smart dma) with a JTAG tap, that tap should be called the ``sdma'' tap.
-@item @b{When in doubt} - use the chip maker's name in their data sheet.
-@end itemize
-@item @b{DOTTED.NAME}
-@* @b{CHIPNAME}.@b{TAPNAME} creates the tap name, aka: the
-@b{Dotted.Name} is the @b{CHIPNAME} and @b{TAPNAME} combined with a
-dot (period); for example: @b{xilinx.tap}, @b{str912.flash},
-@b{omap3530.jrc}, or @b{stm32.cpu} The @b{dotted.name} is used in
-numerous other places to refer to various taps.
-@item @b{ORDER}
-@* The order this command appears via the config files is
-important.
-@item @b{Multi Tap Example}
-@* This example is based on the ST Microsystems STR912. See the ST
-document titled: @b{STR91xFAxxx, Section 3.15 Jtag Interface, Page:
+For example, the ST Microsystems STR912 chip has
+three separate TAPs@footnote{See the ST
+document titled: @emph{STR91xFAxxx, Section 3.15 Jtag Interface, Page:
 28/102, Figure 3: JTAG chaining inside the STR91xFA}.
-
 @url{http://eu.st.com/stonline/products/literature/ds/13495.pdf}
-@*@b{checked: 28/nov/2008}
+Checked: 28-Nov-2008}.
+To configure those taps, @file{target/str912.cfg}
+includes commands something like this:
 
-The diagram shows that the TDO pin connects to the flash tap, flash TDI
-connects to the CPU debug tap, CPU TDI connects to the boundary scan
-tap which then connects to the TDI pin.
-
 @example
-   # The order is...
-   # create tap: 'str912.flash'
-   jtag newtap str912 flash  ... params ...
-   # create tap: 'str912.cpu'
-   jtag newtap str912 cpu  ... params ...
-   # create tap: 'str912.bs'
-   jtag newtap str912 bs  ... params ...
+jtag newtap str912 flash ... params ...
+jtag newtap str912 cpu ... params ...
+jtag newtap str912 bs ... params ...
 @end example
 
-@item @b{Note: Deprecated} - Index Numbers
-@* Prior to 28/nov/2008, JTAG taps where numbered from 0..N this
-feature is still present, however its use is highly discouraged and
-should not be counted upon.  Update all of your scripts to use
-TAP names rather than numbers.
-@item @b{Multiple chips}
-@* If your board has multiple chips, you should be
-able to @b{source} two configuration files, in the proper order, and
-have the taps created in the proper order.
-@comment END NOTES
+Actual config files use a variable instead of literals like
+@option{str912}, to support more than one chip of each type.
+@xref{Config File Guidelines}.
+
+@section TAP Names
+
+When a TAP objects is created with @command{jtag newtap},
+a @dfn{dotted.name} is created for the TAP, combining the
+name of a module (usually a chip) and a label for the TAP.
+For example: @code{xilinx.tap}, @code{str912.flash},
+@code{omap3530.jrc}, @code{dm6446.dsp}, or @code{stm32.cpu}.
+Many other commands use that dotted.name to manipulate or
+refer to the TAP.  For example, CPU configuration uses the
+name, as does declaration of NAND or NOR flash banks.
+
+The components of a dotted name should follow ``C'' symbol
+name rules:  start with an alphabetic character, then numbers
+and underscores are OK; while others (including dots!) are not.
+
+@quotation Tip
+In older code, JTAG TAPs were numbered from 0..N.
+This feature is still present.
+However its use is highly discouraged, and
+should not be counted upon.
+Update all of your scripts to use TAP names rather than numbers.
+Using TAP numbers in target configuration scripts prevents
+reusing on boards with multiple targets.
+@end quotation
+
+@anchor{TAP Creation Commands}
+@section TAP Creation Commands
+
+@c shouldn't this be(come) a {Config Command}?
+@anchor{jtag newtap}
+@deffn Command {jtag newtap} chipname tapname configparams...
+Creates a new TAP with the dotted name @var{chipname}.@var{tapname},
+and configured according to the various @var{configparams}.
+
+The @var{chipname} is a symbolic name for the chip.
+Conventionally target config files use @code{$_CHIPNAME},
+defaulting to the model name given by the chip vendor but
+overridable.
+
+@cindex TAP naming convention
+The @var{tapname} reflects the role of that TAP,
+and should follow this convention:
+
+@itemize @bullet
+@item @code{bs} -- For boundary scan if this is a seperate TAP;
+@item @code{cpu} -- The main CPU of the chip, alternatively
+@code{arm} and @code{dsp} on chips with both ARM and DSP CPUs,
+@code{arm1} and @code{arm2} on chips two ARMs, and so forth;
+@item @code{etb} -- For an embedded trace buffer (example: an ARM ETB11);
+@item @code{flash} -- If the chip has a flash TAP, like the str912;
+@item @code{jrc} -- For JTAG route controller (example: the ICEpick modules
+on many Texas Instruments chips, like the OMAP3530 on Beagleboards);
+@item @code{tap} -- Should be used only FPGA or CPLD like devices
+with a single TAP;
+@item @code{unknownN} -- If you have no idea what the TAP is for (N is a number);
+@item @emph{when in doubt} -- Use the chip maker's name in their data sheet.
+For example, the Freescale IMX31 has a SDMA (Smart DMA) with
+a JTAG TAP; that TAP should be named @code{sdma}.
 @end itemize
-@comment at command level
 
-@section Enable/Disable Taps
-@b{Note:} These commands are intended to be used as a machine/script
-interface. Humans might find the ``scan_chain'' command more helpful
-when querying the state of the JTAG taps.
+Every TAP requires at least the following @var{configparams}:
 
-@b{By default, all taps are enabled}
+@itemize @bullet
+@item @code{-ircapture} @var{NUMBER}
+@*The IDCODE capture command, such as 0x01.
+@item @code{-irlen} @var{NUMBER}
+@*The length in bits of the
+instruction register, such as 4 or 5 bits.
+@item @code{-irmask} @var{NUMBER}
+@*A mask for the IR register.
+For some devices, there are bits in the IR that aren't used.
+This lets OpenOCD mask them off when doing IDCODE comparisons.
+In general, this should just be all ones for the size of the IR.
+@end itemize
 
+A TAP may also provide optional @var{configparams}:
+
 @itemize @bullet
-@item @b{jtag tapenable} @var{DOTTED.NAME}
-@item @b{jtag tapdisable} @var{DOTTED.NAME}
-@item @b{jtag tapisenabled} @var{DOTTED.NAME}
+@item @code{-disable} (or @code{-enable})
+@*Use the @code{-disable} paramater to flag a TAP which is not
+linked in to the scan chain when it is declared.
+You may use @code{-enable} to highlight the default state
+(the TAP is linked in).
+@xref{Enabling and Disabling TAPs}.
+@item @code{-expected-id} @var{number}
+@*A non-zero value represents the expected 32-bit IDCODE
+found when the JTAG chain is examined.
+These codes are not required by all JTAG devices.
+@emph{Repeat the option} as many times as required if more than one
+ID code could appear (for example, multiple versions).
 @end itemize
-@cindex tap enable
-@cindex tap disable
-@cindex JRC
-@cindex route controller
+@end deffn
 
-These commands are used when your target has a JTAG route controller
-that effectively adds or removes a tap from the JTAG chain in a
-non-standard way.
+@c @deffn Command {jtag arp_init-reset}
+@c ... more or less "init" ?
 
-The ``standard way'' to remove a tap would be to place the tap in
-bypass mode. But with the advent of modern chips, this is not always a
-good solution. Some taps operate slowly, others operate fast, and
-there are other JTAG clock synchronisation problems one must face. To
-solve that problem, the JTAG route controller was introduced. Rather
-than ``bypass'' the tap, the tap is completely removed from the
-circuit and skipped.
+@anchor{Enabling and Disabling TAPs}
+@section Enabling and Disabling TAPs
+@cindex TAP events
 
+In some systems, a @dfn{JTAG Route Controller} (JRC)
+is used to enable and/or disable specific JTAG TAPs.
+Many ARM based chips from Texas Instruments include
+an ``ICEpick'' module, which is a JRC.
+Such chips include DaVinci and OMAP3 processors.
 
-From OpenOCD's point of view, a JTAG tap is in one of 3 states:
+A given TAP may not be visible until the JRC has been
+told to link it into the scan chain; and if the JRC
+has been told to unlink that TAP, it will no longer
+be visible.
+Such routers address problems that JTAG ``bypass mode''
+ignores, such as:
 
-@itemize @bullet
-@item @b{Enabled - Not In ByPass} and has a variable bit length
-@item @b{Enabled - In ByPass} and has a length of exactly 1 bit.
-@item @b{Disabled} and has a length of ZERO and is removed from the circuit.
+@itemize
+@item The scan chain can only go as fast as its slowest TAP.
+@item Having many TAPs slows instruction scans, since all
+TAPs receive new instructions.
+@item TAPs in the scan chain must be powered up, which wastes
+power and prevents debugging some power management mechanisms.
 @end itemize
 
-The IEEE JTAG definition has no concept of a ``disabled'' tap.
-@b{Historical note:} this feature was added 28/nov/2008
+The IEEE 1149.1 JTAG standard has no concept of a ``disabled'' tap,
+as implied by the existence of JTAG routers.
+However, the upcoming IEEE 1149.7 framework (layered on top of JTAG)
+does include a kind of JTAG router functionality.
 
-@b{jtag tapisenabled DOTTED.NAME}
+@c (a) currently the event handlers don't seem to be able to
+@c     fail in a way that could lead to no-change-of-state.
+@c (b) eventually non-event configuration should be possible,
+@c     in which case some this documentation must move.
 
-This command returns 1 if the named tap is currently enabled, 0 if not.
-This command exists so that scripts that manipulate a JRC (like the
-OMAP3530 has) can determine if OpenOCD thinks a tap is presently
-enabled or disabled.
+@deffn Command {jtag cget} dotted.name @option{-event} name
+@deffnx Command {jtag configure} dotted.name @option{-event} name string
+At this writing this mechanism is used only for event handling,
+and the only two events relate to TAP enabling and disabling.
 
-@page
-@node Target Configuration
-@chapter Target Configuration
+The @code{configure} subcommand assigns an event handler,
+a TCL string which is evaluated when the event is triggered.
+The @code{cget} subcommand returns that handler.
+The two possible values for an event @var{name}
+are @option{tap-disable} and @option{tap-enable}.
+
+So for example, when defining a TAP for a CPU connected to
+a JTAG router, you should define TAP event handlers using
+code that looks something like this:
+
+@example
+jtag configure CHIP.cpu -event tap-enable @{
+  echo "Enabling CPU TAP"
+  ... jtag operations using CHIP.jrc
+@}
+jtag configure CHIP.cpu -event tap-disable @{
+  echo "Disabling CPU TAP"
+  ... jtag operations using CHIP.jrc
+@}
+@end example
+@end deffn
+
+@deffn Command {jtag tapdisable} dotted.name
+@deffnx Command {jtag tapenable} dotted.name
+@deffnx Command {jtag tapisenabled} dotted.name
+These three commands all return the string "1" if the tap
+specified by @var{dotted.name} is enabled,
+and "0" if it is disbabled.
+The @command{tapenable} variant first enables the tap
+by sending it a @option{tap-enable} event.
+The @command{tapdisable} variant first disables the tap
+by sending it a @option{tap-disable} event.
+
+@quotation Note
+Humans will find the @command{scan_chain} command more helpful
+than the script-oriented @command{tapisenabled}
+for querying the state of the JTAG taps.
+@end quotation
+@end deffn
+
+@node CPU Configuration
+@chapter CPU Configuration
 @cindex GDB target
 
-This chapter discusses how to create a GDB debug target.  Before
-creating a ``target'' a JTAG tap DOTTED.NAME must exist first.
+This chapter discusses how to create a GDB debug target for a CPU.
+You can also access these targets without GDB
+(@pxref{Architecture and Core Commands}) and, where relevant,
+through various kinds of NAND and NOR flash commands.
+Also, if you have multiple CPUs you can have multiple such targets.
 
+Before creating a ``target'', you must have added its TAP to the scan chain.
+When you've added that TAP, you will have a @code{dotted.name}
+which is used to set up the CPU support.
+The chip-specific configuration file will normally configure its CPU(s)
+right after it adds all of the chip's TAPs to the scan chain.
+
 @section targets [NAME]
 @b{Note:} This command name is PLURAL - not singular.
 
@@ -2067,7 +2116,7 @@
 @section TARGETNAME (object) commands
 @b{Use:} Once a target is created, an ``object name'' that represents the
 target is created. By convention, the target name is identical to the
-tap name. In a multiple target system, one can preceed many common
+tap name. In a multiple target system, one can precede many common
 commands with a specific target name and effect only that target.
 @example
     str912.cpu    mww 0x1234 0x42
@@ -2242,22 +2291,6 @@
 @* Success
 @item @b{resumed}
 @* Target has resumed
-@item @b{tap-enable}
-@* Executed by @b{jtag tapenable DOTTED.NAME} command. Example:
-@example
-jtag configure DOTTED.NAME -event tap-enable @{
-  puts "Enabling CPU"
-  ...
-@}
-@end example
-@item @b{tap-disable}
-@*Executed by @b{jtag tapdisable DOTTED.NAME} command. Example:
-@example
-jtag configure DOTTED.NAME -event tap-disable @{
-  puts "Disabling CPU"
-  ...
-@}
-@end example
 @end itemize
 
 @anchor{Target Create}
@@ -2338,6 +2371,11 @@
   @}
 @end example
 
+@b{PROBLEM:} On more complex chips, the work area can become
+inaccessible when application code enables or disables the MMU.
+For example, the MMU context used to acess the virtual address
+will probably matter.
+
 @section Target Variants
 @itemize @bullet
 @item @b{cortex_m3}