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>
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>
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>
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 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>
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
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
Update the board config for the DaVinci DM355 EVM so the reset-init
event handler does the rest of the work it should do:
- minor PLL setup bugfixes
- initialize the DDR2 controller
- probe both NAND banks
- initialize UART0
- enable the icache
git-svn-id: svn://svn.berlios.de/openocd/trunk@2699 b42882b7-edfa-0310-969c-e2dbd0fdcd60
defining ntrst_delay is pointless; don't.
At least the LM3S3748 eval board doesn't need nsrst_delay
either; remove that too.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2645 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- remove endianness options; these chips hard-wire "little"
- $_TARGETNAME updates:
* don't pass $_TARGETNAME where a TAP label is required
* flash config uses $_TARGETNAME (it might not be target #0)
* simplify one $_TARGETNAME construction
- update work area setup:
* remove VM spec; these chips have no VM!
* fix some wrong sizes (0x4000 == 16K, not 4K)
* simplify: take defaults
- comment fixups
git-svn-id: svn://svn.berlios.de/openocd/trunk@2589 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Add flash programming support for NXP LPC1700 cortex_m3 based family
git-svn-id: svn://svn.berlios.de/openocd/trunk@2579 b42882b7-edfa-0310-969c-e2dbd0fdcd60
on ARM9 cores, and update the DaVinci config files so they
no longer explicitly specify it.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2484 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Prepare the DaVinci PLL code to support the version 0x0E module
used in newer chips (e.g. dm365): rename the original code so
it's specific to version 0x02 PLL modules, and update the dm355evm
code to use that new name.
Fix two minor bugs in that version 2 code: sysclk3 setup used
the sysclk2 divider address (affecting video processing on dm355,
no worry for now) and sysclk2 setup had a syntax error.
Also minor fixups to dm355evm, mostly to permit use of RTCK.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2447 b42882b7-edfa-0310-969c-e2dbd0fdcd60
This patch adds support for the Luminary Micro LM3S9B90 target and
LM3S9B92 Evaluation Kit. These kits include a new ft2232 adapter, the
Luminary In-Circuit Debug Interface (ICDI) Board, so this is added as a
new ft2232 layout called "luminary_icdi".
git-svn-id: svn://svn.berlios.de/openocd/trunk@2429 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Minor bugfix ... previous version was tested *with* ICEpick active.
The "-disable" can swap with "-enable"; but not with an empty string.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2418 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Improve the PXA255 target config: move all that board-specific
setup to the pxa255_sst board.cfg, to which it evidently belongs
(it's the only PXA255 board now included).
Provide the PXA255 JTAG id from Intel docs, and add a comment
about how this chip is now EOL'd (last orders taken).
Note that I still can't get my old PXA255 board to work. There's
something broken in the reset sequence, which is preventing the
TAP from coming up at all. Old mailing list posts suggest this
is a longstanding bug...
git-svn-id: svn://svn.berlios.de/openocd/trunk@2416 b42882b7-edfa-0310-969c-e2dbd0fdcd60
source the STM32 target config instead of using a private clone
git-svn-id: svn://svn.berlios.de/openocd/trunk@2352 b42882b7-edfa-0310-969c-e2dbd0fdcd60
an improved DM355, integrating much better HD video support,
Ethernet, and other goodies.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2351 b42882b7-edfa-0310-969c-e2dbd0fdcd60
David Brownell
Spencer Oliver
Wookey
Øyvind Harboe
Dean Glazeski
Rabeeh Khoury
John Rigby
oharboe
dbrownell
mlu
ntfreak
duane
zwelch