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

instead of a target number.


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

Still defaults to nonstandard EMU0/EMU1 settings.


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

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

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

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

It can be sped up later, once it's known the PLLs are active.

Note that modern tools from TI all use adaptive clocking; and
that if that's done with OpenOCD, "too fast" is also a non-issue.


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

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

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

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

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