That syntax has been obsolete forever and is now gone; remove a few
remaining references. Shows how seldom this stuff gets used.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Common target.cfg file for LM3S CPU family
[dbrownell@users.sourceforge.net: rename, generalize more]
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Behave like OMAP3530: force global software reset. Given the
patch to teach ARM11 how to use these events, and use VCR to
catch the reset vector, this works better than either the
current reset logic or than using SRST.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Rename the "armv4_5" command prefix to straight "arm" so it makes
more sense for newer cores. Add a simple compatibility script.
Make sure all the commands give the same "not an ARM" diagnostic
message (and fail properly) when called against non-ARM targets.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Kick in ETM (and ETB) support for ARM11. Tested on OMAP 2420,
so update that configuration. (That's an ARM1136ejs, ETB,
OpenGL ES1.1, C55x DSP, etc.)
Also update the other ARM11 ETM + ETB targets in the tree
to set up these modules. (Not tested.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Various cores with an ETB have its TAP misnamed ... either as a
boundary scan TAP or as the iMX "Secure JTAG Controller" (which
is, among other things, a JRC that could be used to shorten
scan chains).
Use the correct name for these TAPs, which we can recognize since
their IDs were assigned by ARM and these chips all document the
presence of an ETB. The 0x2b900f0f is ETB11; the 0x1b900f0f
is an older module, just called "ETB".
Also shrink the ETB's IR configuration; the default IR-Capture
value is fine, and the mask can specify that all four bits are
safe to check (per ARM documentation).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
General rule, this is all board-specific and doesn't belong
in target config files. Some of these were just cosmetic.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Here's a patch for the double-reset problem on STM32. I've tested
downloading and debugging with GDB and Eclipse, and everything seems
to work fine.
This effectively sets reset_config to none. trst_only would also
be ok, but that's better left to a board configuration file since
not all boards wire it up.
The NVIC is used to trigger reset, which at least on this chip also
pulses nSRST so the whole system does get rest -- exactly once.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
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>
The semantics of "-work-area-virt 0" (or phys) changed with
the patch to require specifying physical or virtrual work
area addresses. Specifying zero was previously a NOP. Now
it means that address zero is valid.
This patch addresses three related issues:
- MMU-less processors should never specify work-area-virt;
remove those specifications. Such processors include
ARM7TDMI, Cortex-M3, and ARM966.
- MMU-equipped processors *can* specify work-area-virt...
but zero won't be appropriate, except in mischievous
contexts (which hide null pointer exceptions).
Remove those specs from those processors too. If any of
those mappings is valid, someone will need to submit a
patch adding it ... along with a comment saying what OS
provides the mapping, and in which context. Example,
say "works with Linux 2.6.30+, in kernel mode". (Note
that ARM Linux doesn't map kernel memory to zero ...)
- Clarify docs on that "-virt" and other work area stuff.
Seems to me work-area-virt is quite problematic; not every
operating system provides such static mappings; if they do,
they're not in every MMU context...
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Config for Intel's "Lubbock" PXA255 development board. Even more
so than the PXA255 itself, this is obsolete. AFAIK this was the
first generally available development platform for PXA255. Intel
stopped providing these after other devel boards became available.
One interesting thing about this board from the OpenOCD perspective
is probably its flash configuration. Each bank is 32 bits wide,
built from two 16-bit StrataFlash chips wired in parallel. This
doubles throughput ... it reads/writes 32 bits in the time a single
chip takes to write just 16 bits.
This conf mostly works, given XScale bugfixes, but has some issues
(notably: no access to the on-board SDRAM) flagged by FIXMEs.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
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>
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
Update the Beagle setup:
- OMAP3530 updates:
* split ICEpick TAP enable support to its own file, for
reuse and eventually for storing other utility code
like emulation reset
* clean up, including labeling the tap as for DAP not
for the Cortex-A8 and making endianness non-variable
* add a few FIXMEs
- BeagleBoard cleanup: there's no SRST, "endstate" is gone, etc
I'm not sure I'd say it's further than "barely limping" just yet.
Key issues remain lack of Cortex-A8 support, and more complete
support for resetting.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2267 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Fix for a goofy "board" config ... reuse target/pxa270.cfg
instead of using a private copy.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2266 b42882b7-edfa-0310-969c-e2dbd0fdcd60
DM6446 config updates:
- List two more TAPs, as disabled, mostly for doc purposes
- Included basic ICEpick support, still disabled by default
- Shorten line lengths
- Use $_TARGETNAME to configure the ETM and ETB
- This ARM core don't support endianness overriding
For now, boards that can't jumper EMU0/EMU1 will need to tweak
a variable's setting.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2265 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Add another board ... OMAP2420 "H4" board. This won't be very widely
used with OpenOCD, but with mainline support in both U-Boot and Linux
it at least makes for a more complete set (and another testcase).
This is incomplete support in several respects. The ARM11 support is
not very deep yet; most registers aren't available, and the ETM can't
be hooked up. Plus, there's no script for OMAP-specific stuff like
setting up the SDRAM controller. Eventually the same NAND controller
driver should work with OMAP2 and OMAP3.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2242 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Tweak the csb337 code so that it doesn't enable alignment traps when
it completes the "reset init" sequence. It turns out that the current
CFI code reliably triggers such traps.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2179 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Add configuration for an old AT91rm9200 board, the Cogent CSB 337.
Worth noting from the OpenOCD perspective:
- It got a real hardware trace port connector; wired up here as
much as we can, lacking inexpensive trace-aware dongles.
- This is the first in-tree use of the "arm920t cp15" command.
It adjusts the CPU clocking and enables i-cache, which gives
more than 4x speedup after booting Linux; it's visible even
just running U-Boot.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2134 b42882b7-edfa-0310-969c-e2dbd0fdcd60
This is the missing half of the r1974 patch:
OSK5912 board support, which was split out from
the omap5912 target config.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1985 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Split out OSK5912 board support from the omap5912 target config, and make
it pass sanity checks on my (Rev C/original) hardware:
- Fix syntax error ("-irlen" not "irlen")
- Provide real TAP ids for the ARM926ejs and the C55x dsp
- Label both CPUs appropriately (DSP, ARM)
- List both flash chips
The scan chain looks like this (note truncated DSP instruction code):
TapName | Enabled | IdCode Expected IrLen IrCap IrMask Instr
---|--------------------|---------|------------|------------|------|------|------|---------
0 | omap5912.dsp | Y | 0x03df1d81 | 0x03df1d81 | 0x26 | 0x00 | 0x00 | 0xffffffff
1 | omap5912.arm | Y | 0x0692602f | 0x0692602f | 0x04 | 0x01 | 0x00 | 0x0c
2 | omap5912.unknown | Y | 0x00000000 | 0x00000000 | 0x08 | 0x00 | 0x00 | 0xff
I still don't know what that third TAP is; maybe an early version of
an ICEpick JTAG router.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1974 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Move src/tcl to tcl/.
- Update top Makefile.am to use new path name.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1919 b42882b7-edfa-0310-969c-e2dbd0fdcd60
David Brownell
mkdorg@users.sourceforge.net
Øyvind Harboe
Yegor Yefremov
Marek Vasut
Zachary T Welch
Thomas Kindler
Krzysztof Kajstura
Freddie Chopin
Dimitar Dimitrov
Oleg Seiljus
Spencer Oliver
Wookey
Dean Glazeski
Rabeeh Khoury
John Rigby
oharboe
dbrownell
mlu
ntfreak
duane
zwelch