srst_pulls_trst is only true on some (broken) LPC2148 boards, a fact
which is already documented in doc/openocd.texi, so it shouldn't be
set unconditionally in the target tcl.
This patch was needed to reflash when an Abort exception occured very
early after reset, before OpenOCD tried to halt the CPU.
Globally rename "jtag_nsrst_delay" as "adapter_nsrst_delay", and move it
out of the "jtag" command group ... it needs to be used with non-JTAG
transports
Includes a migration aid (in jtag/startup.tcl) so that old user scripts
won't break. That aid should Sunset in about a year.
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>
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>
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>
- 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
- Move src/target/{interface,target,board,test}/ into src/tcl/
- Remove existing rules in src/Makefile.am and src/target/Makefile.am.
- Add Makefile.am handling of *.cfg and *.tcl files in top Makefile.am:
- Add dist-hook to include such files under src/tcl in the distribution.
- Add install-data-hook to install contents of '$(top_srcdir)/src/tcl/'.
- Add uninstall-hook to remove the installed script files.
- Change paths to (un)install script files in '$(pkgdatadir)/scripts'.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1918 b42882b7-edfa-0310-969c-e2dbd0fdcd60
This was forgotten here. All other LPC targets use
this option.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1906 b42882b7-edfa-0310-969c-e2dbd0fdcd60
if they're the same for all LPC214x, this number is from an Olimex
LPC-H2148. The chip on that board is LPC2148FBD64.
Also fix a few cosmetic issues and comments in the file and add
more docs and pointers to the datasheet.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1427 b42882b7-edfa-0310-969c-e2dbd0fdcd60
messages a bit. The file and line # of the syntax error
in a reset script is now printed.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1042 b42882b7-edfa-0310-969c-e2dbd0fdcd60
to daemon_startup(still supported).
- print warning if srst and trst change state at the same time when srst_and_trst
is seperate
- reset now performs a trst, examines and validates the jtag chain before targets
assert reset
- if startup fails to examine and validate the jtag chain, try a reset before
trying again
git-svn-id: svn://svn.berlios.de/openocd/trunk@552 b42882b7-edfa-0310-969c-e2dbd0fdcd60