and Tcl/external):
- Reorder so *both* paths (TCK/TMS or TRST) can enable TAPs with
ICEpick ... first C code flags TAPs that got disabled, then call
any Tcl code that might want to re-enable them.
- Always call the C/internal handlers when JTAG operations can be
issued; previously that wasn't done when TRST was used.
Plus some small cleanups (whitespace, strings, better messaging
during debug and on some errors) to reset-related code.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2730 b42882b7-edfa-0310-969c-e2dbd0fdcd60
avoid a duplicate test.
Plus other cleanup in the same code: be "static", sane line lengths
for source and diagnostics, and fix misleading variable names.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2725 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Erase logic:
- command invocation
+ treat "nand erase N" (no offset/length) as "erase whole chip N"
+ catch a few more bogus parameter cases, like length == 0 (sigh)
- nand_erase() should be static
- on error
+ say which block failed, and if it was a bad block
+ don't give up after the first error; try to erase the rest
- on success, say which nand device was erased (name isn't unique)
Device list ("nand list"):
- say how many blocks there are
- split summary into two lines
- give example in the docs
Doc tweaks:
- Use @option{...} for DaVinci's supported hardware ECC options
For the record, I've observed that _sometimes_ erasing bad blocks causes
failure reports, and that manufacturer bad block markers aren't always
erasable (even when erasing their blocks doesn't trigger an error report).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2724 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- update comments to say so.
- update docs to clarify that the "arm9tdmi" command prefix
is a misnomer.
- bugfix some messages that wrongly assume only ARM9TDMI
based processors use this code.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2719 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Cleanup some the downloaded ARM target algorithm code:
- Provide more complete disassembly of the DCC bulk write code
- Make code blocks "static const", in case GCC doesn't
- Fix some tabbing/layout issues
- Make some arm7_9_common.h flags be "bool" not "int"; and compact
the layout a bit (group most bools together)
git-svn-id: svn://svn.berlios.de/openocd/trunk@2698 b42882b7-edfa-0310-969c-e2dbd0fdcd60
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
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
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
that were added after ARMv5TE was defined:
- ARMv5J "BXJ" (for Java/Jazelle)
- ARMv6 "media" instructions (for OMAP2420, i.MX31, etc)
Compile-tested. This might not set up the simulator right for the
ARMv6 single step support; only BXJ branches though, and docs to
support Jazelle branching are non-public (still, sigh).
ARMv6 instructions known to be mis-handled by this disassembler
include: UMAAL, LDREX, STREX, CPS, SETEND, RFE, SRS, MCRR2, MRRC2
git-svn-id: svn://svn.berlios.de/openocd/trunk@2644 b42882b7-edfa-0310-969c-e2dbd0fdcd60
With DCCR we are asking the CPU to halt, we should wait until
the CPU has halted before proceeding with the operation.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2638 b42882b7-edfa-0310-969c-e2dbd0fdcd60
the ITR register but it will only be executed when the DSCR[13]
bit is set. The documentation is a bit weird as it classifies
the DSCR as read-only but the pseudo code is writing to it as
well. This is working on a beagleboard.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2634 b42882b7-edfa-0310-969c-e2dbd0fdcd60
instruction to be finished. This comes from the pseudo code
of the cortex a8 trm.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2632 b42882b7-edfa-0310-969c-e2dbd0fdcd60
"next iteration" step with the rest of the loop overhead.
Cleanup: remove spurious whitespace, and an overlong line;
only assign "tap->hasidcode" once.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2631 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Bugfixes:
* internal osc: it's *12* MHz (not 15 MHz) on _current_ chips
+ except new Tempest parts where it's 16 MHz (and calibrated!)
+ or some old Sandstorm ones, where 15 MHz was valid
* crystal config:
+ read and use the crystal config, don't assume 6 MHz
+ know when that field is 4 bits vs 5
* an RCC2 register may be overriding the original RCC
+ more clock source options
+ bigger dividers
+ fractional dividers on Tempest (NYET handled)
* there's a 30 KHz osc on newer chips (for deep sleep)
* there's a 32768 Hz osc on newer chips (for hibernation)
- Cosmetic
* say "rev A0" not "vA.0", to match vendor docs
* don't always report master clock as an "estimate":
+ give the error bound if it's approximate, like "±30%"
+ else don't say anything
* fix whitespace and caps in some messages
* these are not AT91SAM chips!!
Those clock issues might explain problems sometimes reported when
writing to Stellaris flash banks; they affect write timings.
That 12-vs-15 MHz issue is problematic; there's no consolidated doc
showing which chips (and revs!) have which internal oscillator speed.
It's clear that only older silicon had the faster-and-less-accurate
flavor. What's less clear is which chips are "old" like that.
Lightly tested, on a DustDevil part.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2626 b42882b7-edfa-0310-969c-e2dbd0fdcd60
For ARMv4/ARMv5:
- better command parameter error checking
- don't require an instruction count; default to one
- recognize thumb function addresses
- make function static
- shorten some too-long lines
For Cortex-M3:
- don't require an instruction count; default to one
With the relevant doc updates.
---
Nyet done: invoke the thumb2 disassembler on v4/v5,
to better handle branch instructions.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2624 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Unify the handling of the req_srst parameter, and rip out a
large NOP branch and its associated FIXME. (There didn't seem
to be anything that needs fixing; but that was unclear since
the constraints were scattered all over the place not unified.)
git-svn-id: svn://svn.berlios.de/openocd/trunk@2623 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Unify the handling of the req_tlr_or_trst parameter. Basically,
JTAG TMS+TCK ops ("TLR") is always used ... unless TRST is a safe
option in this system configuration.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2622 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Track whether TRST and/or SRST actually change:
* If they're not changing, don't ask the JTAG adapter to do anything!
(JTAG TCK/TMS ops might still be used to enter TAP_RESET though.)
* Don't change their recorded values until after the adapter says it
did so ... so fault paths can't leave corrupt state.
* Detect and report jtag_execute_queue() failure mode
* Only emit messages saying what really changed; this includes adding
an omitted "deasserted TRST" message.
* Only apply delays after deasserting SRST/TRST if we *DID* deassert!
- Messages say "TLR" not "RESET", to be less confusing; there are many
kinds of reset. (Though "TLR" isn't quite ideal either, since it's
the name of the TAP state being entered by TMS+TCK or TRST; it's at
least non-ambiguous in context.)
So the main effect is to do only the work this routine was told to do;
and to have debug messaging make more sense.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2621 b42882b7-edfa-0310-969c-e2dbd0fdcd60
reset operations. Maybe they can't; or it's a "not yet" thing.
Note that the assert/deassert operations can't yet trigger for
OMAP3 because resets currently include JTAG reset in all cases,
resetting the ICEpick and thus disabling the TAP for Cortex-A8.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2620 b42882b7-edfa-0310-969c-e2dbd0fdcd60
the values that are written in the mini-IC (plus documentation updates that
describe why this is needed).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2613 b42882b7-edfa-0310-969c-e2dbd0fdcd60
nonfunctional cortex_a8 code with something that at least basically
works (for halt/step/resume, without MMU) even if it is incomplete.
(With tweaks from Øyvind, and cleanup from Dave.)
This code has mainly been developed and tested against R1606, it has
been built and tested against R2294 where it runs but step and resume
commands are broken due to regression (which should be fixed now).
This code is really written for OMAP3530. It doesn't identify debug
resources using generic DAP calls to scan the ROM table, or perform
topology detection. The OMAP3530 DAP exposes two memory access ports:
- Port #0 is connected to L3 interconnect (the main bus) with
passthrough to the L4 EMU bus ... so it will be used for most
memory accesses.
- Port #1 is connected to a dedicated debug bus (L4 EMU), with
access to L4 Wakeup, and holds the ROM table ... so it must
be used for most debug and control operations.
The are some defines to handle this in cortex_a8.c, which should be
replaced with more general code. Having access to another Cortex-A8
implementation would help get that right.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2609 b42882b7-edfa-0310-969c-e2dbd0fdcd60
and seed it with DAP access support using the current ADIv5 code.
(With tweaks and cleanup from Øyvind and Dave.)
The ARMv7-AR architecture manual is not publicly available (even
in subset form like the ARMv7-M spec), so it's hard to distinguish
between the Cortex-A8 implementation and the ARMv7-A architecture.
The register set presumably is architectural, and so it's stored
here; it's like earlier ARMs, with small additions. Ditto the
instruction set, though Thumb2 support is used (extending Thumb
support from ARMv6 with more 32-bit instructions) and there's this
ThumbEE thing too. There is a new "debug monitor" mode, not yet
fully addressed here, to support debugging in environments (like
motor control) where halting debug mode is inadvisable.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2608 b42882b7-edfa-0310-969c-e2dbd0fdcd60
The trunk is currently broken for interfaces without
the speed_div function (interface specific clock speed
value to kHz conversion). Example: parport.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2605 b42882b7-edfa-0310-969c-e2dbd0fdcd60
SVF file, making OpenOCD compatible with files generated by
Altera Quatrus II 9.0.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2600 b42882b7-edfa-0310-969c-e2dbd0fdcd60
mlu
dbrownell
oharboe
ntfreak
duane