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>
Add the 'nand verify' command to perform a dump and fake-write
simultaneously, checking the read bits against those generated by the
write process. Appropriate user documentation for this command has
been added to the user guide as well.
The algorithm presently makes a relatively naive comparison. Some chips
that use ECC may not verify correctly using this implementation, but the
new documentation provides details about this limitation.
ARM11 and newer cores include updated ETM modules. Recognize
their version codes and some key config differences. Sanity
checked on an OMAP2, with an ETM11RV r0p1 (ETMv3.1).
This still handles only scan chain 6, with at most 128 registers.
Newer cores (mostly, Cortex) will need to use the DAP instead.
Note that the newer ETM modules don't quite fit the quirky config
model of the older ones ... having more port widths is easy, but
the modes aren't the same. That still needs to change.
Fix a curious bug ... how did the register cache NOT get saved??
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Add the khz and speed_div functions to the parport interface driver.
Add the parport_toggling_time function that tells the parport driver
how long (in nanoseconds) it takes for the hardware to toggle TCK.
[dbrownell@users.sourceforge.net: tweak doc for clarity, mention
multimeter, and whitespace fixes]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Start switching MMU handling over to a more sensible scheme.
Having an mmu() method enables MMU-aware behaviors. Not having
one kicks in simpler ones, with no distinction between virtual
and physical addresses.
Currently only a handful of targets have methods to read/write
physical memory: just arm720, arm920, and arm926. They should
all initialize OK now, but the arm*20 parts don't do the "extra"
stuff arm926 does (which should arguably be target-generic).
Also simplify how target_init() loops over all targets by making
it be a normal "for" loop, instead of scattering its three parts
to the four winds.
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>
Rename the "Drivers, Options, and Commands" sections to be
just "Driver List" matching the earlier reference. Add an
example of parallel CFI flash.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The "$ocd_HOSTOS" variable was wrongly documented. Fix its
documentation, and its value on Linux.
Shrink a few of the too-long lines.
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>
Highlight that the "-expected-id" probably comes from vendor
documentation, and that it *should* be used where possible.
Don't use ircapture/irmask in examples, to help discourage
use of those params when they're not required. Explain a
bit better about why/when those params get used.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Mention the autoprobing as a tool that may be useful when
figuring out how to set up; and add a section showing how
to use that mechanism (with an example).
Strengthen the differences between config and run stage
descriptions; add a section for the latter.
Mention Dragonite.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Bit 5 shouldn't be used. Remove all support for modifying it.
Matches the exception vector table, of course ... more than one
bootloader uses that non-vector to help distinguish valid boot
images from random garbage in flash.
The register names are perversely not documented as zero-indexed,
so rename them to match that convention. Also switch to lowercase
suffixes and infix numbering, matching ETB and EmbeddedICE usage.
Update docs to be a bit more accurate, especially regarding what
the "trigger" event can cause; and to split the issues into a few
more paragraphs, for clarity.
Make "configure" helptext point out that "oocd_trace" is prototype
hardware, not anything "real".
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
XSVF improvements:
- Layer parts of XSVF directly over SVF, calling svf_add_statemove()
instead of expecting jtag_add_statemove() to conform to the SVF/XSVF
requirements (which it doesn't).
This should improve XSTATE handling a lot; it removes most users of
jtag_add_statemove(), and the comments about how it should really do
what svf_add_statemove() does.
- Update XSTATE logic to be a closer match to the XSVF spec. The main
open issue here is (still) that this implementation doesn't know how
to build and submit paths from single-state transitions ... but now
it will report that error case.
- Update the User's Guide to mention the two utility scripts for
working with XSVF, and to mention the five extension opcodes.
Handling of state transition paths is, overall, still a mess. I think
they should all be specified as paths not unlike SVF uses, and compiled
to the bitstrings later ... so that we can actually make sense of the
paths. (And see the extra clocks, detours through RUN, etc.)
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>
Fix formatting and layout bugs in the new "translating configuration
files" bit. Make it a section within the chapter about config files.
Add a crossreference.
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>
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
It had a very little bit of content; move that to the more extensive
chapter on config file guidelines, and give more current "ls" output
to show the available library code.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2820 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 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
- 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
- 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
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
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
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
Highlight that the "post-reset" event kicks in before the
scan chain is validated, which limits what can be done
in a post-reset handler.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2745 b42882b7-edfa-0310-969c-e2dbd0fdcd60
done on exit from the config stage, how JTAG clocking issues can
trigger errors there, and how to avoid such problems.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2737 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
JTAG clocking by gating the core clock, and workarounds.
Most details are with the "halt" command, which is one
of the first places this issue will be noticed.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2718 b42882b7-edfa-0310-969c-e2dbd0fdcd60
David Brownell
Zachary T Welch
Jonas Horberg
Øyvind Harboe
dbrownell
oharboe