Remove useless typedef from struct jtag_command.

Remove misleading typedef from union jtag_container.

Remove misleading typedef from struct sleep_command.

Remove misleading typedef from struct end_state_command.

Remove misleading typedef from struct reset_command.

Remove misleading typedef from struct stableclocks_command.

Remove misleading typedef from struct runtest_command.

Remove misleading typedef from struct pathmove_command.

Remove misleading typedef from struct statemove_command.

Remove misleading typedef from struct cmd_queue_page.

Remove misleading typedef on struct scan_command.

Remove useless typedef for struct insert_insignification_operation.

Remove misleading typedef and redundant suffix.

Remove useless typedef.

Remove misleading typedef from ft2232_device; it was barely used.

Remove misleading typedef and redundant suffix.

Remove useless typedef and redundant suffix from parport struct cable.

Remove misleading typedef from struct struct pending_scan_result.
Future patches need to remove these duplicated types and code.

Remove useless typedef and redundant suffix from struct armjtatew_jtag.

Remove useless typedef and redundant suffix from jtag_tap_event_action.

Remove useless typedef and redundant suffix from jtag_event_callback.
Add documentation for the structure.

Remove useless typedef and redundant suffix from struct jtag_interface.

Removes another useless typedef and suffix.

Remove useless typedef and redundant suffix.

Move the bitq_state structure from the header to source file, as it
is used internally.

Also removes its silly typedef.

Remove useless structure typedef.

Search and destroy the jtag_tap_t typedef.  This also cleans up a
layering violation, removing the declaration from types.h.

The number of command arguments will always be 0 or more, so use
the right type in handlers.  This has a cascading effect up through
the layers, but the new COMMAND_HANDLER macros prevented total chaos.

By introducing the CMD_NAME macro, this parameter may be integrated
as args[-1] in command.[ch], without touching any other call sites.

By using CALL_COMMAND_HANDLER, parameters can be reordered, added, or
even removed in inherited signatures, without requiring revisiting
all of the various call sites.

Define the numerous helpers that inherit command handler parameters
using the COMMAND_HELPER macro.

Add the khz and speed_div functions to the parport interface driver.
Add the parport_toggling_time function that tells the parport driver
how long (in nanoseconds) it takes for the hardware to toggle TCK.

[dbrownell@users.sourceforge.net: tweak doc for clarity, mention
multimeter, and whitespace fixes]

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

Without this patch, running "openocd -c 'jtag interface'" segfaults.
Now, it returns the string "undefined" when the interface is unset.

Contrary to my previous assessment, some opportunities to remove forward
declarations were overlooked.  Remove them by moving the definitions
of the command registration and interface structure to the end of files.

It's been about a year since these were deprecated and, in most
cases, removed.  There's no point in carrying that documentation,
or backwards compatibility for "jtag_device" and "jtag_speed",
around forever.  (Or a few remnants of obsolete code...)

Removed a few obsolete uses of "jtag_speed":

 - The Calao stuff hasn't worked since July 2008.  (Those Atmel
   targets need to work with a 32KHz core clock after reset until
   board-specific init-reset code sets up the PLL and enables a
   faster JTAg clock.)
 - Parport speed controls don't actually work (tops out at about
   1 MHz on typical HW).
 - In general, speed controls need to live in board.cfg files (or
   sometimes target.cfg files), not interface.cfg ...

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

Removes the 'extern' keyword from function declarations.
Wraps long prototypes to fit into 80 columns.

Fixes documentation for jtag_tap_s::{,has}idcode fields.

Previous patch somehow made GCC lose some of its cookies;
work around, zero-init that struct.

Clean up code from the previous patch.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

This change is necessary to debug AT91SAM9260 on my PC with a
FT2232H dongle.

Signed-off-by: Dimitar Dimitrov <dinuxbg@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

This patch includes partial support for these new JTAG adapters.
More complete support will require updates to the libftdi code,
for EEPROM access.

[dbrownell@users.sourceforge.net: fix whitespace, linelen, etc ]

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

Don't log "Yes, I'm *still* in TAP_IDLE" every seven runtest clocks.

Get rid of needless variable, improve and shrink diagnostic.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

This patch adds basic autoprobing support for the JTAG scan chains
which cooperate.  To use, you can invoke OpenOCD with just:

 - interface spec: "-f interface/...cfg"
 - possibly with "-c 'reset_config ...'" for SRST/TRST
 - possibly with "-c 'jtag_khz ...'" for the JTAG clock

Then set up config files matching the reported TAPs.  It doesn't
declare targets ... just TAPs.  So facilities above the JTAG and
SVF/XSVF levels won't be available without a real config; this is
almost purely a way to generate diagnostics.

Autoprobe was successful with most boards I tested, except ones
incorporating C55x DSPs (which don't cooperate with this scheme
for IR length autodetection).  Here's what one multi-TAP chip
reported, with the "Warn:" prefixes removed:

 clock speed 500 kHz
 There are no enabled taps.  AUTO PROBING MIGHT NOT WORK!!
 AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x2b900f0f ..."
 AUTO auto1.tap - use "jtag newtap auto1 tap -expected-id 0x07926001 ..."
 AUTO auto2.tap - use "jtag newtap auto2 tap -expected-id 0x0b73b02f ..."
 AUTO auto0.tap - use "... -irlen 4"
 AUTO auto1.tap - use "... -irlen 4"
 AUTO auto2.tap - use "... -irlen 6"
 no gdb ports allocated as no target has been specified

The patch tweaks IR setup a bit, so we can represent TAPs with
undeclared IR length.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

Stop allocating three bytes per IR bit, and cope somewhat better
with IR lengths over 32 bits.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

Some cosmetic cleanup, and switch to a single table mapping
between state names and symbols (vs two routines which only
share that state with difficulty).

Get rid of TAP_NUM_STATES, and some related knowledge about
how TAP numbers are assigned.  Later on, this will help us
get rid of more such hardwired knowlege.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

- Use the name mappings all the other code uses:
    + name-to-state ... needed to add one special case
    + state-to-name
 - Improve various diagnostics:
    + don't complain about a "valid" state when the issue
      is actually that it must be "stable"
    + say which command was affected
 - Misc:
    + make more private data and code be static
    + use public DIM() not private dimof()
    + shorten the affected lines

Re the mappings, this means we're more generous in inputs we
accept, since case won't matter.  Also our output diagnostics
will be a smidgeon more informative, saying "RUN/IDLE" not
just "IDLE" (emphasizing that there can be side effects).

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

XSVF improvements:

 - Layer parts of XSVF directly over SVF, calling svf_add_statemove()
   instead of expecting jtag_add_statemove() to conform to the SVF/XSVF
   requirements (which it doesn't).

   This should improve XSTATE handling a lot; it removes most users of
   jtag_add_statemove(), and the comments about how it should really do
   what svf_add_statemove() does.

 - Update XSTATE logic to be a closer match to the XSVF spec.  The main
   open issue here is (still) that this implementation doesn't know how
   to build and submit paths from single-state transitions ... but now
   it will report that error case.

 - Update the User's Guide to mention the two utility scripts for
   working with XSVF, and to mention the five extension opcodes.

Handling of state transition paths is, overall, still a mess.  I think
they should all be specified as paths not unlike SVF uses, and compiled
to the bitstrings later ... so that we can actually make sense of the
paths.  (And see the extra clocks, detours through RUN, etc.)

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>