Passing "--std=gun99" is unfortunately not sufficient to make current
MinGW compilers conform with respect to checking printf format strings.
(The C runtime seems not to have problems.)
Fix by using a "gnu_printf" format specifier not "printf".
Use JIM_WIDE_MODIFIER for the sscanf format, and apply it for MINGW32 as
well as other Windows environments. (Microsoft doesn't conform to the
C99 standard, and uses "%I64d" not "%lld" for "long long".)
NB: __MINGW32__ should work on both w32 and w64,.
Generate a C struct with the data, and use that, instead of an
assembly language file. The assembly language causes issues on
Darwin and MS-Windows, which don't necessarily use GNU AS; or
if they do, don't necessarily use its ELF syntax.
It's also better in two other ways: fewer global symbols; and
the init-time size check gets optimized away at compile time.
(Unless it fails, in which case bigger chunks of the file vanish.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Based on some patches from <redirect.slash.nil@gmail.com>
for preliminary Win64 compilation. More such updates are
needed, but they need work. Compile tested on 64 and 32 bit
Linuxes, and Cygwin.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This makes the documentation a closer match to "help" output:
- "pathmove" somehow was not documented in the User's Guide
- "jtag_nsrst_assert_width" and "jtag_ntrst_assert_width"
are new; both needed descriptions.
- Removed two undocumented and fairly useless script mechanisms:
* production/production_info/production_test ... using it,
requires replacing everything; so having it adds no value.
* cpu ... way out of date; hopeless to keep that current
Note that anyone using that "production" stuff already defines
their own procedures, and can keep using them with no change.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The LE check is obviously buggy (as easily triggered during some
testing), but I didn't audit the rest of the cases.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cleanup comments and layout/whitespace in the TMS tables.
Table contents stayed the same (ignoring whitespace).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Resolve a "FIX" comment; yes that was superfluous given that the
JTAG core does that check by default. It was also buggy since it
wrote to a stack frame that went away before the write happened!!
Other fixes: remove pointless malloc(); zero-init scan_field_t
values wherever they appear; whitespace scrub; spelling fix.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Load the XScale debug handler from the read-only data section
instead of from a separate file that can get lost or garbaged.
This eliminates installation and versioning issues, and also
speeds up reset handling a bit.
Plus some minor bits of cleanup related to loading that handler:
comments about just what this handler does, and check fault codes
while writing it into the mini-icache.
The only behavioral changes should be cleaner failure modes after
errors during handler loading, and being a bit faster.
NOTE: presumes GNU assembly syntax, with ".incbin"; and ELF,
because of the syntax of the ".size" directive.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Streamline/shrink some needless JTAG stuff:
- Use #defines for the JTAG instructions; they can't ever change
- Remove an unused (!) shadow of tap->ir_length
- Stop using a copy of target->tap
- Don't bother saving the variant after sanity checking ir_length
Also, make target_create() work as on other targets: build the
register cache later, making init_target() no longer be a NOP.
Handle malloc failure; remove a comment that was obsoleted by the
not-so-new target syntax.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Remove unused and deprecated (in the arch spec) mode for loading
code into the *main* icache (vs the "mini" icache). Disable some
extremely noisy (and rarely useful) low-level debug messages
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Declare almost everything as static.
Move stuff to remove most forward references.
Remove most forward declarations.
Warn if the unimplemented register functions get called.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Just fill out the rest of the cache line with NOPs; don't change
the record of how much data we consumed. Otherwise the count of
how much data is left can roll over from positive to negative
("VERY positive") and skip the loop termination of zero.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Add a header comment referencing useful XScale specs.
Make most data static, and the tables readonly.
Scrub extra blank lines.
Return fault codes from one routine.
Remove a needless NOP methood.
(BUGFIX) When we update R0, mark R0 as dirty/valid ... not R15/PC!
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
We added two overridable procedures; document them, and the
two jtag arp_* operations they necessarily expose.
Update the comment about the jtag_init_reset() routine; it's
been obsolete for as long as it's had SRST support.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This abstracts the "jtag arp_init-reset" call into a method
called from OpenOCD startup and reset processing.
Platforms which have different requirements for how such hard
resets must be performed can now override "init_reset" instead
of needing to rebuild custom hacked versions of the server.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Observed:
openocd: core.c:318: jtag_checks: Assertion `jtag_trst == 0' failed.
The issue was that nothing disabled background polling during calls
from the TCL shell to "jtag_reset 1 1". Fix by moving the existing
poll-disable mechanism to the JTAG layer where it belongs, and then
augmenting it to always pay attention to TRST and SRST.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Among other things this causes startup errors to kick in the
fallback "reset harder" logic during server startup. Comments
are also updated a bit, explaining what the various error paths
signify (in at least my observation).
There's one class of validation error that we can still plausibly
ignore: when wrong IDCODE values are observed.
This change seems to have helped make an OMAP5912 behave much
more reliably. There's still some post-reset flakiness, but
it's unrelated to scan verification.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Also, talk about "mainline" not "trunk".
The release.txt and release.sh files need more updates.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2825 b42882b7-edfa-0310-969c-e2dbd0fdcd60
At least some FT2232 based adapters don't necessarily come up
in the expected state, with SRST and TRST disabled. Since
other adapters could suffer the same problem, let's avoid
needing to patch every driver and just force *all* adapters
to initialize those values properly at server startup.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2824 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Instead of just assuming all IDCODE-deprived TAPs violate the
JTAG spec (they don't!), just require TAPs with such problems
to be declared with proper ircapture/irmask values. Example,
with mask and value of zero.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2823 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- revert to previous default: don't talk JTAG during SRST
- add "srst_nogates" flag, the converse of "srst_gates_jtag"
- with no args, display the current configuration
And update the User's Guide text with bullet lists to be a bit more clear.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2818 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- The guess-rev.sh script is now a tweaked version of "setlocalversion" as
seen in Linux, U-Boot, and various other projects. When it finds source
control support (git, hg, svn) it uses IDs from there. Else (specific
to this project) it reports itself as "-snapshot", e.g. from gitweb.
I verified this new "guess-rev.sh" script runs under Cygwin.
- Also update the generic version strings to be like "0.3.0-dev" (during
development) instead of the very long "0.3.0-in-development". These also
show up in the PDF docs. For better tracking, we might eventually change
these strings to include the version IDs too.
- Change the startup banner version strings so they include the guess-rev
output. Development and release versions with GIT will be like
Open On-Chip Debugger 0.3.0-dev-00282-g7191a4f-dirty (2009-10-05-20:57)
Open On-Chip Debugger 0.3.0 (2009-10-05-20:57)
instead of the previous SVN-specific (even when using git-svn!)
Open On-Chip Debugger 0.3.0-in-development (2009-10-05-01:39) svn:exported
Open On-Chip Debugger 0.3.0 (2009-10-05-01:39) Release
git-svn-id: svn://svn.berlios.de/openocd/trunk@2809 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Bugfix the error message so it shows the disliked value, and add
a debug message showing each TAP's IR capture value, all N bits.
This just changes diagnostics ... it still ignores the parameters
given to us at TAP declaration time.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2801 b42882b7-edfa-0310-969c-e2dbd0fdcd60
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
- don't needlessly export this function
- handle "case 0" debug method-of-entry better (silent by default)
The "case 0" is a valid debug entry mode so it doesn't deserve the
warning int now gets. But it probably means that OpenOCD confused
itself somehow; or that it confused the ARM9EJS target.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2799 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- ETB
* report _actual_ hardware status, not just expected status
* add a missing diagnostic on a potential ETB setup error
* prefix any diagnostics with "ETB"
- ETM
* make "etm status" show ETM hardware status too, instead of
just traceport status (which previously was fake, sigh)
- Docs
* flesh out "etm tracemode" docs a bit
* clarify "etm status" ... previously it was traceport status
* explain "etm trigger_percent" as a *traceport* option
ETM+ETB tracing still isn't behaving, but now I can see that part of
the reason is that the ETB turns itself off almost immediately after
being enabled, and before collecting any data.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2790 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Don't issue needless JTAG resets ... only do them after
errors. Normal exit now leaves every TAP in BYPASS.
- Fix an unlikely memory leak on one fault path.
- Remove the oddball limitation that invalid capture LSBs
trigger errors only for TAPs that support IDCODE.
Re the JTAG reset: there are too many of them, and they can
(and do!) change system state. So the needless ones should
get removed. This one was especially pointless.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2777 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Commands were supposed to have been "arm11 memwrite ..."
not "memwrite ..."
- Get rid of obfuscatory macros
- Re-alphabetize
- Add docs for "arm11 vcr"
git-svn-id: svn://svn.berlios.de/openocd/trunk@2776 b42882b7-edfa-0310-969c-e2dbd0fdcd60
When the OpenOCD server starts up it records its state as TAP_RESET,
even though it could be anything. Then when it starts to examine
the scan chain, it calls jtag_add_tlr() which sees it doesn't have
any work to do, and so it does nothing. This can make the next
operations fail because they start from the wrong TAP state...
Instead of caring about the current recorded state, always enter
TAP_RESET by forcing five clocks with TMS high.
(NOTE: it seems most other JTAG adapter drivers have this same bug.)
git-svn-id: svn://svn.berlios.de/openocd/trunk@2763 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Change the handling of the "-ircapture" and "-irmask" parameters
to be slightly more sensible, given that the JTAG spec describes
what is required, and that we already require that conformance in
one place. IR scan returns some bitstring with LSBs "01".
- First, provide and use default values that satisfy the IEEE spec.
Existing TAP configs will override the defaults, but those parms
are no longer required.
- Second, warn if any TAP gets set up to violate the JTAG spec.
It's likely a bug, but maybe not; else this should be an error.
Improve the related diagnostics to say which TAP is affected.
And associated minor fixes/cleanups to comments and diagnostics.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2758 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Ready for discussion and tiny patches that tries out this scheme.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2755 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Added gdb_sync feature that allows GDB to sync up to target state.
Issue "monitor gdb_sync" and the next stepi, will return immediately
with updated register values to GDB.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2754 b42882b7-edfa-0310-969c-e2dbd0fdcd60
make sure that when there are two or more targets, their
various pre/post event reports are correctly ordered.
Previously, only the first target always saw its "pre"
method before SRST was asserted or deasserted.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2753 b42882b7-edfa-0310-969c-e2dbd0fdcd60
only expose the registers which are actually present. They
could be missing for two basic reasons:
- This version might not support them at all; e.g. ETMv1.1
doesn't have some control/status registers. (My sample of
ARM9 boards shows all with ETMv1.3 support, FWIW.)
- The configuration on this chip may not populate as many
registers as possible; e.g. only two data value comparators
instead of eight.
Includes a bugfix in the "etm info" command: only one of the
two registers is missing on older silicon, so show the first
one before bailing.
Update ETM usage docs to explain that those registers need to be
written to configure what is traced, and that some ETM configs
are not yet handled. Also, give some examples of the kinds of
constrained trace which could be arranged.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2752 b42882b7-edfa-0310-969c-e2dbd0fdcd60
system, removes 20 non-existent registers ... but still includes
over 45 (!) ETM registers which don't even exist there ...
- Integrate the various tables to get one struct per register
- Get rid of needless per-register dynamic allocation
- Double check list of registers:
* Remove sixteen (!) non-registers for data comparators
* Remove four registers that imply newer ETM than we support
* Change some names to match current architecture specs
- Handle more register info
* some are write-only
* some are read-only
* record which versions have them, just in case
- Reorganize the registers to facilitate removing the extras
* group e.g. comparator/counter #N registers together
* add and use lookup-by-ID
git-svn-id: svn://svn.berlios.de/openocd/trunk@2751 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Add a header comment
- Line up the ETM context struct, pack it a bit
- Remove unused context_id (this doesn't support ETMv2 yet)
- Make most functions static
- Remove unused string table and other needless lines of code
- Correct "tracemode" helptext
Also provide and use an etm_reg_lookup() to find entries in the ETM
register cache. This will help cope with corrected contents of that
cache, which doesn't include entires for non-existent registers.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2750 b42882b7-edfa-0310-969c-e2dbd0fdcd60
didn't turn up earlier. Is everyone still using gcc 3.x? Or is the x86
version of gcc 4.x much more relaxed?
git-svn-id: svn://svn.berlios.de/openocd/trunk@2749 b42882b7-edfa-0310-969c-e2dbd0fdcd60
of a (NOR) flash chip: allow passing "last" as an alias
for the number of the last sector.
Improve several aspects of error checking while we're at it.
From: Johnny Halfmoon <jhalfmoon@milksnot.com>
git-svn-id: svn://svn.berlios.de/openocd/trunk@2746 b42882b7-edfa-0310-969c-e2dbd0fdcd60
garbage after the expected data (from the TAPs' BYPASS or IDCODE
registers).
NOTE that there was previously some code that looked like it was
trying to do this ... which didn't work, because it was looping
over the list of expected TAPs, and never checked *after* that
list completed! That could hide some *nasty* reset issues...
Also replace a now-obsolete scanchain length test with one that
behaves correctly; and update reporting of unexpected IDCODEs.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2739 b42882b7-edfa-0310-969c-e2dbd0fdcd60
This patch modifies an error message which, in its original state,
I find somewhat unhelpful. So a small hint was added.
Signed-off-by: Johnny Halfmoon <jhalfmoon at milksnot.com>
git-svn-id: svn://svn.berlios.de/openocd/trunk@2738 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Shrink messaging during resets, primarily by getting rid of
"nothing happened" noise that hides *useful* information.
- Improve: the "no IDCODE" message by identifying which tap only
supports BYPASS; and the TAP event strings.
Related minor code updates:
- Remove two needless tests when examining the chain: we know
we have a TAP, and that all TAPs have names.
- Clean up two loops, turning "while"s into "for"s which better
show what's actually being done.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2736 b42882b7-edfa-0310-969c-e2dbd0fdcd60
for disabling TAPs. We don't actually know how to make any
JRCs which do that yet; but when we do, this will matter.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2735 b42882b7-edfa-0310-969c-e2dbd0fdcd60
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
- warning now issued if high speed ftdi device found and openocd was built using an old driver
git-svn-id: svn://svn.berlios.de/openocd/trunk@2599 b42882b7-edfa-0310-969c-e2dbd0fdcd60
ARMv7-M: A5.3.6 Load/store dual or exclusive, table branch
GCC will generate the table branch instructions, usually with inlined
tables that will confuse this disassembler. LDREX and STREX are not
issued by GCC without inline assembly.
This means all Thumb2 instructions implemented by Cortex-M3 can now
be disassembled. Cortex-A8 cores support more Thumb2 instructions,
but most of those aren't yet publicly documented.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2598 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- spell "address" right
- list bp/wp params as optional
And make those source lines wrap at sane margins.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2596 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- AIRCR_SYSRESETREQ is generic; use it on any system where
SRST won't fly, not just on Stellaris-based ones.
- Reformat and improve comments about the Stellaris quirk; and
xref the only public docs (an email) about the issue.
It seems that *most* Stellaris chips have this problem. Tempest
parts aren't yet in general sampling; and if rev B silicon for
earlier chips exists, it's not very visible yet.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2595 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Simplify dumping of register lists by only printing cached values
if they are marked as valid. Most of the time, they are invalid;
so printing *any* value is just misleading.
Note that for ARM7 and ARM9 most EmbeddedICE registers (except for
debug status) could be cached most of the time; and their register
cache isn't maintained properly (many accesses seem to bypass that
cache code).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2594 b42882b7-edfa-0310-969c-e2dbd0fdcd60
https://lists.berlios.de/pipermail/openocd-development/2009-August/009939.html
1. It can only be built with the FTD2XX driver. libftdi supports FT2232H/FT4232H
since version 0.16
2. A speed value of 0 is used as a RTCK request indicator. This clashes with the
valid clock division value 0 that provide the highest fixed clock frequency.
3. The ft2232_speed_div function return the maximum selectable frequency (30MHz)
when RTCK is activated. It should return 0.
4. The ft2232_khz function return ERROR_OK when RTCK is requested even for
devices lacking RTCK support. It should return ERROR_FAIL so the upper driver layers
can detect this and try to fallback to a fixed frequency.
5. FT2232H/FT4232H have a backward compatibility function that divide the clock
by 5 to get the same frequency range as FT2232D. There is no code that disable
this functionality. I can not find anything about if this is enabled or disabled by default.
I think it is safest to actively disable it.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2591 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Change jtag_rclk behaviour so it can be called before the interface init function
git-svn-id: svn://svn.berlios.de/openocd/trunk@2590 b42882b7-edfa-0310-969c-e2dbd0fdcd60
issue with this is that the core debug support uses this
mechanism, then trashes its state over reset. Users can
Work around that (for now) by re-assigning the desired
config after reset.
Also fixes "target halted due to target-not-halted" goof.
When we can't describe the reason using OpenOCD's limited
vocabulary, say "reason undefined" instead of saying it's
not halted.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2588 b42882b7-edfa-0310-969c-e2dbd0fdcd60
arrays (error prone) or assume all registers are 32-bits wide (they can
have fewer bits); don't use spaces in register names, so they can be
passed more easily to the "reg" command.
Minor updates for ARM9 vector_catch support: it's an 8-bit value. This
seems to help this core's vector_catch command work a bit better; but its
behavior wih the register cache is still goofy.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2587 b42882b7-edfa-0310-969c-e2dbd0fdcd60
display them as 32 bits unless that's their true size.
(Removes some confusion.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2586 b42882b7-edfa-0310-969c-e2dbd0fdcd60
OpenOCD was able to access only to chips attached to first EMIF
chipselect. This patch fixes chipselect management code and allows
OpenOCD to access to NAND devices attached to any EMIF CS line.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2585 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
Warn about anyone using "jtag_speed" commands; that command is obsolete, and will someday be removed.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2578 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- revert patch from rev1507 as it was causing reset issues with arm9 cores
git-svn-id: svn://svn.berlios.de/openocd/trunk@2574 b42882b7-edfa-0310-969c-e2dbd0fdcd60
A5.3.11 Data processing (shifted register)
The usual kinds of problems; the most noteworthy were that
the "S"et flags bit was mis-handled in these instructions.
---
This is the last patch from a quickie set of tests covering all
encodings of the instructions with 32-bit opcodes. There may
be some corner cases left, plus the instructions that aren't
yet handled, but the Thumb2 disassembler is no longer just
"lightly" tested with GCC output ... the new code paths have
mostly been verified.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2568 b42882b7-edfa-0310-969c-e2dbd0fdcd60
A5.3.5 Load/store multiple
A5.3.7 Load word
There was a longstanding bug in Thumb-1 LDM; the rest of the LDM/STM
fixes are just using width specs to match UAL syntax, except for two
opcode name typos. Load word had two bitmask goofs.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2567 b42882b7-edfa-0310-969c-e2dbd0fdcd60
A5.3.8 Load halfword, unallocated memory hints
It's mostly the usual sort of bitmasking goofage and getting the
width specs right. In one case an older x86 GCC generated bad code
unless I structred a conditional differently (sigh).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2566 b42882b7-edfa-0310-969c-e2dbd0fdcd60
A5.3.5 Load/store multiple
A5.3.7 Load word
There was a longstanding bug in Thumb-1 LDM; the rest of the LDM/STM
fixes are just using width specs to match UAL syntax, except for two
opcode name typos. Load word had two bitmask goofs.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2565 b42882b7-edfa-0310-969c-e2dbd0fdcd60
ARMv7-M arch manual:
A5.3.1 Data processing (modified immediate)
A5.3.3 Data processing (plain binary immediate)
A5.3.4 Branches and miscellaneous control
and other (immediate) encodings referenced there. Several of
these just tweak the new syntax ("Unified" ARM/Thumb: UAL) but
there were a few bugs too.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2564 b42882b7-edfa-0310-969c-e2dbd0fdcd60
with testcases covering several new encodings in these sections
of the ARMv7-M arch manual:
A5.3.12 Data processing (register)
A5.3.13 Miscellaneous operations
A5.3.14 Multiply, and multiply accumulate
A5.3.15 Long multiply, long multiply accumulate, and divide
The issues were mostly in '12 and '13; some new related 16-bit
opcodes had issues too.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2563 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Dump SP on poll, and show whether it's MSP or PSP.
Thread mode can use either stack pointer, so this is
part of the state that's not yet displayed.
Shrink some lines.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2555 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Clean up treatment of registers in ARMv7-M and Cortex-M3.
- At the arch level:
* Just list registers and names; don't impose core-specific
policy about how they are accessed.
* Each register has a symbol.
* Remove the register mode field (irrelevant to debugger)
- At the core/implementation level:
* Just map the registers to their relevant access methods;
don't require the arch level to say how that should work
(cores other than Cortex-M3 could do it differently).
* Don't use undefined bits from register 20.
* Use register IDs that are part of the ARMv7-M interface.
In short, there's now a real distinction between the arch
and core layers.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2554 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Minor updates to the Thumb2 disassembly:
- Bugfixes:
* Distinguish branch from misc via "!=" not "=="
* MRS register shift is 8 bits (vs MSR being 16)
- Format tweaks:
* CPS needed tab (not space)
* add commma before some shifts
* add space after comma in LDM/STM
* use ".W" width spec on various instructions
git-svn-id: svn://svn.berlios.de/openocd/trunk@2553 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Revert parts of the previous ARMv7-M register patch.
It turns out that part of the issue is a documentation
problem for the Cortex-M3 r1 parts. So for the rest,
simpler fixes are possible (in followup patch).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2552 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- fix issue when multiple flash chips are connected, eg. x16 x 2 on 32bit mcu bus
git-svn-id: svn://svn.berlios.de/openocd/trunk@2551 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Move the dap command handler implementations to arm_adi_v5.c,
leaving just thin wrappers in armv7m.c. There should be no
change in functionality here. (From Magnus.)
Minor style cleanup: whitespace, line length, etc. Update spec
references to use docs which are currently available. (From Dave.)
git-svn-id: svn://svn.berlios.de/openocd/trunk@2544 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Some cleanup of the ARMv7-M support:
- Reference the relevant ARMv7-M ARM doc (DDI 0405C to non-Vendors), and
update the Cortex-M3 doc refs (DDI 0337C is no longer available).
- Those registers aren't actually general, and some are incorrect (per all
public docs anyway). Update comments and code accordingly.
* What the Core Debug facility exposes is *implementation-specific*
not architectural. These values aren't fully portable. They match
Cortex-M3 ... so no current implementation will make trouble, but
the next v7m implementation might.
* Four of the registers are actually not exposed that way. Before
Cortex-M3 r2p0 they are read/written through MRS/MSR instructions.
In that newest silicon, they are four bytes in one register, not
four separate registers.
- Update the CM3 code to report when that one register is available,
and not try to access it when it isn't. Also declare the register
numbers that an eventual MRS/MSR solution will need to be using.
- Stop line wrapping the exception labels.
So for parts before r2p0 OpenOCD behavior is effectively unchanged, and
still buggy; but for those newer parts a few things might now be correct.
Most current Cortex-M3 parts use r1p1 (or earlier); this seems to include
most LM3S parts and all STM32 parts. Parts using r2p0 are available, and
include fourth generation LM3S parts ("Tempest") plus AT91SAM3 and LPC17xx
parts which are now sampling.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2543 b42882b7-edfa-0310-969c-e2dbd0fdcd60
More instructions decoded:
A5.3.5 Load/store multiple
The preferred PUSH/POP syntax is shown when appropriate.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2539 b42882b7-edfa-0310-969c-e2dbd0fdcd60
More instructions decoded:
A5.3.14 Multiply, and multiply accumulate
A5.3.15 Long multiply, long multiply accumulate, divide
The EABI requires *adjacent* register pairs, but the long multiply
ops can use any pair of registers; interesting.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2538 b42882b7-edfa-0310-969c-e2dbd0fdcd60
More Thumb2 32-bit opcode support:
A5.3.10 Store single data item
Byte, word, halfword. Offset, pre-index, post-index. And
a "make like you're unprivileged" option when using small
immediate offsets.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2537 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Print old-style Thumb NOP instructions as such. (GCC uses "mov r8, r8"
instead of the architected NOP which is new in Thumb2.)
git-svn-id: svn://svn.berlios.de/openocd/trunk@2536 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Redirect 'Slash' NIL
David Brownell
Øyvind Harboe
David Brownell
Lennert Buytenhek
Yauheni Kaliuta
dbrownell
oharboe
mlu
ntfreak
duane
zwelch