Gets rid of the runtime warning "stm32.bs: nonstandard IR mask"

[dbrownell@users.sourceforge.net: line lengths, note issue, section ref]

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

This gets rid of runtime warnings from the use of numbers.
STM32 and LPC2103 were tested.  Other LPC updates are the
same, and so are safe.  The CFI updates match other tested
changes now in the tree.

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

Add interface configs for two new high speed JTAG
adapters from Olimex.  They need some other speed
related tweaks to work well at high speed.

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>

Add configs for H2, H4, LITE.

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

These chips need both SRST and TRST when debugging,
and SRST doesn't gate JTAG.

Now I can issue "reset halt" and have everything act smoothly;
the vector_catch hardware is obviously not kicking in, but the
rest of the reset sequence acts sanely.

 - TAP "setup" event enables the DAP, not omap3_dbginit
   (resolving a chicken/egg bug I noted a while back)
 - Remove stuff from omap3_dbginit which should never be
   used in event handlers
 - Cope better with slow clocking during reset

Also, stop hard-wiring the target name: use the input params in
the standard way, and set up $_TARGETNAME as an output param.

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

Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>

This is the very basic board config for the balloon3 board cpu JTAG
channel.

The rest of the config comprises another 14 .cfg files which I suspect
openocd doesn't really want all of. I'm still not sure how to deal
with this. I'll post another mail/patch to discuss.

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

Lightly tested on dm365.

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

Ofrwarded from Ron, who's not subscribed.

----- Forwarded message from Ron <ron@debian.org> -----

From: Ron <ron@debian.org>
Date: Wed, 14 Oct 2009 04:50:17 +1030
To: wookey@debian.org
Subject: [PATCH] OpenRD board configuration
X-Spam-Status: No, score=-3.6 required=4.5 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.2.5

This piggybacks on the 'sheevaplug' layout which uses the same Kirkwood SoC.

Signed-off-by: Ron Lee <ron@debian.org>

Remove ircapture/mask attributes.  Add "srst_nogate".

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

Supply default reset_config statement to make target scripts useful standalone and provide sensible default

Startup now mostly works, except that the initial target state
is "unknown" ... previously, it refused to even start.

Getting that far required fixing the ircapture value (which
can never have been correct!) and the default JTAG clock rate,
then providing custom reset script.

The "reset" command is still iffy.  DCSR updates, and loading
the debug handler, report numerous DR/IR capture failures.
But once that's done, "poll" reports that the CPU is halted
(which it shouldn't be, this was "reset run"!), due to the
rather curious reason "target-not-halted".

Summary:  you still can't debug these parts, but it's closer.

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

This function is used by the SheevaPlug installer to flash the
erase and re-flash the U-Boot environment in the NAND Flash.

This is clearly noted in the hardware spec (section 5.2.3); it
works around a chip erratum:  "If the MPU_RESET signal is used,
it may cause the EMIFS bus to lock."

I seem to have a board with such an initial build.  The chip
is labeled XOMAP.  Presumably, parts without that "X" prefix
(eXperimental) resolve this.

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

Without some extra delay after releasing SRST, we seemed to
be trying to talk to the TAP before it was ready to respond.

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

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

git-svn-id: svn://svn.berlios.de/openocd/trunk@2817 b42882b7-edfa-0310-969c-e2dbd0fdcd60

git-svn-id: svn://svn.berlios.de/openocd/trunk@2816 b42882b7-edfa-0310-969c-e2dbd0fdcd60

git-svn-id: svn://svn.berlios.de/openocd/trunk@2808 b42882b7-edfa-0310-969c-e2dbd0fdcd60

From: Nicolas Pitre <nico@fluxnic.net>


git-svn-id: svn://svn.berlios.de/openocd/trunk@2806 b42882b7-edfa-0310-969c-e2dbd0fdcd60

git-svn-id: svn://svn.berlios.de/openocd/trunk@2804 b42882b7-edfa-0310-969c-e2dbd0fdcd60

The model is that this fires after scanchain verification, when it's
safe to call "jtag tapenable $TAPNAME".  So it will fire as part of
non-error paths of "init" and "reset" command processing.  However it
will *NOT* trigger during "jtag_reset" processing, which skips all
scan chain verification, or after verification errors.

ALSO:
 - switch DaVinci chips to use this new mechanism
 - log TAP activation/deactivation, since their IDCODEs aren't verified
 - unify "enum jtag_event" scripted event notifications
 - remove duplicative JTAG_TAP_EVENT_POST_RESET


git-svn-id: svn://svn.berlios.de/openocd/trunk@2800 b42882b7-edfa-0310-969c-e2dbd0fdcd60

so they provide better examples and are easier to maintain.


git-svn-id: svn://svn.berlios.de/openocd/trunk@2797 b42882b7-edfa-0310-969c-e2dbd0fdcd60

git-svn-id: svn://svn.berlios.de/openocd/trunk@2796 b42882b7-edfa-0310-969c-e2dbd0fdcd60

git-svn-id: svn://svn.berlios.de/openocd/trunk@2781 b42882b7-edfa-0310-969c-e2dbd0fdcd60

git-svn-id: svn://svn.berlios.de/openocd/trunk@2779 b42882b7-edfa-0310-969c-e2dbd0fdcd60

git-svn-id: svn://svn.berlios.de/openocd/trunk@2778 b42882b7-edfa-0310-969c-e2dbd0fdcd60

git-svn-id: svn://svn.berlios.de/openocd/trunk@2762 b42882b7-edfa-0310-969c-e2dbd0fdcd60