This patch adds target algorithm support for those flash devices that do not support DQ5 polling. So far they could only be programmed with host algorithm, but this was way too slow.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2682 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Infinite loop bugfix when running tap configure a second time
git-svn-id: svn://svn.berlios.de/openocd/trunk@2681 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Optionally shave time off the armv4_5 run_algorithm() code: let
them terminate using software breakpoints, avoiding roundtrips
to manage hardware ones.
Enable this by using BKPT to terminate execution instead of "branch
to here" loops. Then pass zero as the exit address, except when
running on an ARMv4 core. ARM7TDMI, ARM9TDMI, and derived cores
now set a flag saying they're ARMv4.
Use that mechanism in arm_nandwrite(), for about 3% speedup on a
DaVinci ARM926 core; not huge, but it helps. Some other algorithms
could use this too (mostly flavors of flash operation).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2680 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Fix docs on ARM11 MCR and MRC coprocessor commands:
correct read-vs-write; and describe the params.
(ARM920 and ARM926 have cp15-specific commands; this
approach is more generic. MCR2, MRC2, MCRR, MCRR2,
MRRC, and MRRC2 instructions could also get exposed.)
git-svn-id: svn://svn.berlios.de/openocd/trunk@2679 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Provide an "armv7a disassemble" command. Current omissions include
VFP (except as coprocessor instructions), Neon, and various Thumb2
opcodes that are not available in ARMv7-M processors.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2676 b42882b7-edfa-0310-969c-e2dbd0fdcd60
lean up some loose ends with the ARM disassembler
- Add a header comment describing its current state and uses
and referencing the now-generally-available V7 arch spec
- Support some mode switch instructions:
* Thumb to Jazelle (BXJ)
* Thumb to ThumbEE (ENTERX)
* ThumbEE to Thumb (LEAVEX)
- Improve that recent warning fix (and associated whitespace goof)
- Declare the rest of the internal code and data "static". A
compiler may use this, and it helps clarify the scope of these
routines (e.g. what changes to them could affect).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2675 b42882b7-edfa-0310-969c-e2dbd0fdcd60
By enabling this bit, the processor halts when a debug event
such as breakpoint occurs.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2668 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Abstract the orion_nand_fast_block_write() routine into a separate
routine -- arm_nandwrite() -- so that other ARM cores can reuse it.
Have davinci_nand do so. This faster than byte-at-a-time ops by a
factor of three (!), even given the slowish interactions to support
hardware ECC (1-bit flavor in that test) each 512 bytes; those could
be read more efficiently by on-chip code.
NOTE that until there's a generic "ARM algorithm" structure, this
can't work on newer ARMv6 (like ARM1136) or ARMv7A (like Cortex-A8)
cores, though the downloaded code itself would work just fine there.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2663 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Via code review by Steve Grubb <sgrubb@redhat.com>
Almost innocuous; this is value is checked later, this
check being wrong would make it check stack garbage.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2655 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Via code review by Steve Grubb <sgrubb@redhat.com>
Also minor fixes for the message from "fill": the byte
count is unsigned, not signed; and more importantly,
print the real number of bytes written
git-svn-id: svn://svn.berlios.de/openocd/trunk@2652 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Itemize the list of private customization examples
for openocd.cfg
- Add "override defaults" as a customization, specifically
for the work area (back it up or relocate it)
- Highlight some work area location issues
git-svn-id: svn://svn.berlios.de/openocd/trunk@2651 b42882b7-edfa-0310-969c-e2dbd0fdcd60
on the command line ... matching comment in add_default_dirs().
Without this it's impossible to use a private config file which
happens to have the same name as an installed one. Say, because
you're bugfixing a private copy...
git-svn-id: svn://svn.berlios.de/openocd/trunk@2649 b42882b7-edfa-0310-969c-e2dbd0fdcd60
