this will allow us to use multiple jlink at the same time as when
the USB-Address is specified the PID change from 0x0101 to
(0x101 + usb_adress)
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
This piggy backs on JTAG so it's not yet pretty, but that
seems unavoidable so far given today's OpenOCD internals.
SWD init and data transfer are unfinished and untested, but
that should cause no regressions, and will be addressed by
the time drivers start using this infrastructure. Checking
in whould get the code working better sooner, and turn up any
structural/architectural issues while they're easier to fix.
The debug adapter drivers will provide simple SWD driver
structs with methods that kick in as needed (instead of JTAG).
So far just one adapter driver has been updated (not yet
ready to use or circulate).
The biggest issues are probably
- fault handling, where the ARM Debug Interface V5 pipelining
needs work in both JTAG and SWD modes and
- missing rewrite of block I/O code to work on both of our
Cortex-ready transports (Current code is hard-wired to JTAG);
relates also to the pipelining issue.
- omitted support to activate/deactivate SWO/SWV trace (this is
technically trivial, but configuring what to trace is NOT.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
----
doc/openocd.texi | 17 ++
src/jtag/core.c | 3
src/jtag/interface.h | 4
src/jtag/jtag.h | 2
src/jtag/swd.h | 114 +++++++++++++++++++
src/jtag/tcl.c | 2
src/target/adi_v5_swd.c | 281 ++++++++++++++++++++++++++++++++++++++++++++++--
src/target/arm_adi_v5.c | 8 +
src/target/arm_adi_v5.h | 3
9 files changed, 425 insertions(+), 9 deletions(-)
STMicroelectronics controller SMI is not SPEAr specific.
Rename it and change name to every symbol in the code.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Add support and documentation for STMicroelectronics
SPEAr Serial Memory Interface (SMI).
Code tested on SPEAr3xx only.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
this never panned out and there are enough mistakes in
the code that probably nobody used this.
Use the tcl server and implement a standalone http
app instead works fine.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Document "-n" option in manual;
Modify "echo" command definition as COMMAND_HANDLER to
easily add help message
Add help message aligned with manual.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Stick with the name "gdb_port" even if this command
can be used for other things(disable, named pipes,
anonymous stdin/out pipe). "port" is correct for
probably more than 90% of use cases, if not more.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone (again),
Watchpoints on xscale are quirky, so I thought a little explanation in the
user's manual was warranted.
Comments gratefully received.
Last one, Øyvind :-)
Thanks,
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
This new cmd adds the ability to choose the Cortex-M3
reset method used.
It defaults to using SRST for reset if available otherwise
it falls back to using NVIC VECTRESET. This is known to work
on all cores.
Move any luminary specific reset handling to the stellaris cfg file.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
ocd_ prefix is used internally in OpenOCD as a kludge more
or less to deal with the two kinds of commands that OpenOCD
has.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone. I noticed some incorrect information in the user manual
regarding how the vector table is handled on the xscale, so for your
consideration, here's a short patch that corrects it, and adds a
little more detail I thought might be helpful.
The documentation states that OpenOCD does not attempt to synchronize
the vector tables in memory with those stored in the "mini instruction
cache". In fact, on each resume it does copy from memory to the cache
all entries in the high and low tables that were not previously
defined using the 'xscale vector_table' command. (In
src/target/xscale.c, see xscale_update_vectors(), which is invoked by
xscale_resume().) I take advantage of this during Linux boot-up. The
extra detail describes in general terms how I do this.
Corrections, comments are of course gratefully received.
Thanks,
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Make it scriptable, so code can be conditionalized based on
what transport is in use for the session.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This adds the guts of a transport framework with initialization,
which should work with current JTAG-only configurations (tested
with FT2232).
Each debug adapter can declare the transports it supports, and
exactly one transport is initialized. (with its commands) in
any given OpenOCD session.
* Define a new "struct transport with init hooks and a few
"transport" subcommands to support it:
"list" ... list the transports configured (just "jtag" for now)
"select" ... makes the debug session use that transport
"init" ... initializes the selected transport (internal)
* "interface_transports" ... declares transports the current interface
can support. (Some will do this from C code instead, when there are
no hardware versioning (or other) issues to prevent it.
Plus some FT2232 tweaks, including a few to streamline upcoming
support for an SWD transport (initially for Luminary adapters).
Eventually src/jtag should probably become src/transport, moving
jtag-specific stuff to transport/jtag.
Signed-off-by: David Brownell <db@helium.(none)>
This adds a virtual flash bank driver that allows virtual banks to
be defined that refer to an existing flash bank.
For example the real address for bank0 on the pic32 is 0x1fc00000
but the user program will either be in kseg0 (0xbfc00000) or
kseg1 (0x9fc00000).
This also means that gdb will be aware of all the read only flash
addresses.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
1. fix some errors in jtag.txt(in my personal opinion, please review).
2. remove a broken link
Signed-off-by: Jun Ma <sync.jma@gmail.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
There are a million reasons why cached protection state might
be stale: power cycling of target, reset, code executing on
the target, etc.
The "flash protect_check" command is now gone. This is *always*
executed when running a "flash info".
As a bonus for more a more robust approach, lots of code could
be deleted.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Flash probing must succeed for e.g. gdb load and automatic
hardware/software breakpoints to work.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Clean up the jtag/tcl.c file, which was one of the biggest and
messiest ones in that directory. Do it by splitting out all the
generic adapter commands to a separate "adapter.c" file (leaving
the "tcl.c" file holding only JTAG utilities).
Also rename the little-used "jtag interface" to "adapter_name", which
should have been at least re-categorized earlier (it's not jtag-only).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The mips_m4k_assert_reset has now been restructured
so the variant ejtag_srst is not required anymore.
The ejtag software reset will be used if the target does not
have srst connected.
Remove ejtag_srst from docs.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Globally rename "jtag_nsrst_assert_width" as "adapter_nsrst_assert_width",
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>
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>
Globally rename "jtag_khz" as "adapter_khz", 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. (We may want to
update it to include a nag message too.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This includes a driver and matching config file. This support needs to be
enabled through the initial "configure" (use "--enable-buspirate").
Signed-off-by: Michal Demin <michaldemin@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
We'll need to be able to work with debug adapter interfaces (drivers)
even when they're not used for JTAG ... for example, while there are
multi-transport drivers which support JTAG *and* several other
transports (or just one more, like SWD) there are also adapters
with more limited goals (and no JTAG support at all).
Start decoupling the two concepts ("debug adapter driver", "jtag")
by having two command groups, which initialize separately.
This will help us support OpenOCD sessions using only non-JTAG
transports, in which JTAG commands should not be registered.
Update docs to mention that the JTAG, SVF, and XSVF commands
won't work without a JTAG transport.
Note that at least commands working with SRST are still inappropriately
coupled to JTAG ... inappropriate because (a) SRST is not part of the
JTAG standard, for all that many platforms (like ARM) expect it; and also
(b) because they're used with non-JTAG debug and programming interfaces,
too. They should perhaps become generic "interface" operations at some
point. (Similarly with the clock rate to be used by a given adapter.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Talk more about "debug adapters" instead of only "dongles". Not all
adapters are discrete widgets; some are integrated onto boards. If
we only talk about "dongles" we rule out many valid setups, and help
confuse some users (who may be using Dongle-free environments).
Also start bringing out the point that JTAG isn't the only transport
protocol, even though OpenOCD historically presumes "all is JTAG".
(Not all debug adapters are JTAG adapters, or JTAG-only adapters.)
Plus a few minor fixes (spelling etc) in the vicinity of those changes,
and updates about FT2232H clocking issues (they can go faster than the
older chips, and can support adaptive clocking).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Move semihosting cmd to the arm cmd group.
Targets that support semihosting will setup the
setup_semihosting callback function.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
The Redbee USB is a small form-factor usb stick from Redwire, LLC
(www.redwirellc.com/store), built around a Freescale MC13224V
ARM7TDMI + 802.15.4 radio (plus antenna).
It includes an FT2232H for debugging, with Channel B connected to the
mc13224v's JTAG interface (unusual) and Channel A connected to UART1.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The Redbee Econotag is an open hardware development kit from
Redwire, LLC (www.redwirellc.com/store), for the Freescale
MC13224V ARM7TDMI + 802.15.4 radio.
It includes both an MC13224V and an FT2232H (for JTAG and UART
support). It has flexible power supply options.
Additional features are:
- inverted-F pcb antenna
- 36 GPIO brought out to 0.1" pin header
(includes all peripheral pins)
- Reset button
- Two push buttons (on kbi1-5 and kbi0-4)
- USB-A connector, powered from USB
- up to 16V external input
- pads for optional buck inductor
- pads for optional 32.768kHz crystal
- 2x LEDS on TX_ON and RX_ON
[ dbrownell@users.sourceforge.net: shrink lines; texi ]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Stellaris chips have a procedure for restoring the chip to
what's effectively the "as-manufactured" state, with all the
non-volatile memory erased. That includes all flash memory,
plus things like the flash protection bits and various control
words which can for example disable debugger access. clearly,
this can be useful during development.
Luminary/TI provides an MS-Windows utility to perform this
procedure along with its Stellaris developer kits. Now OpenOCD
users will no longer need to use that MS-Windows utility.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Be a closer match to what I've actually done for the past few cycles.
In particular, hold off pushing repository updates until after the
packages are published, as part of opening the merge window, and
mention the utility commands which actually create the archives.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Specifically the Linux issue of needing "udev" rules, and MS-Windows
needing driver configuration.
Also, update the existing udev note to use the correct name of that
rules file in the source tree.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Sometimes MS-Windows users try to use filesystem names which include
the "#" character. That's generally unwise, since it begins Tcl
comments.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Not all cores and boards support adaptive clocking, so qualify
all advice to use it to depend on core and board support.
It's primarily ARM cores which support this; and many of the
newer ones (like Cortex-M series) don't.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The Doxygen output was previously titled "OpenOCD Reference Manual",
which was quite misleading ... the User's Guide is the reference
manual which folk should consult about how to use the software.
Just rename it to match how it's been discussed previously, and to
bring out its intended audience: developers of this software. As a
rule, Doxygen is only for folk who work with the code it documents.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Have the User's Guide and BUG handling notes both reference
the fact that we now have a bug database at SourceForge.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Remove long-obsolete text about "erase_check" affecting "flash info" output.
Move parts of that text to "protect_check", where it's still relevant; and
update the "flash info" description to mention the issue.
(This is still awkward. It might be best to make "protect_check" mirror
"erase_check" by dumping what it finds, so "flash info" doesn't dump any
potentially-stale cache info.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The "-f" is a shortcut for "-c" ... and providing any "-c" options
means the "openocd.cfg" file isn't implicitly used. Both the User's
Guide and the manual page were weak on these points, which has led
to some confusion.
Also update the manual page to include highlights of the search path
mechanism, including the facts that it exists and that "-s" adds to it.
Stop saying only the current directory is involved; the OpenOCD
script library is quite significant.
(Missing: complete manpage coverage of the search path, including a
FILES section listing all components and saying where the script
library is found.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Highlight the needs to properly jumper development boards; to
make the OpenOCD configuration match the jumpering; and to have
a usable "reset-init" method when debugging early boot code.
Specific mention of the "ATX Mode" that seems useful on
many i.MX boards, forcing NAND boot.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Folk almost certainly want to have OpenOCD compute the checksum
when they modify the vector table. However, that almost guarantees
that "verify_image" will fail.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Identical to the existing 2412/2443 support except for the base address
and NFCONF value (bit 2 is reserved and should be written as 1 ref UM).
Tested on a s3c6410 board, but controller is identical in 6400/6410
except for 8bit MLC ECC support in 6410 which isn't supported by the
driver.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Capture various bits of useful information that have come up on the
list but haven't yet gotten into the documentation:
- Watchdog timers firing during JTAG debug need attention;
- Some chips have special registers to help JTAG debug;
- Cortex-M3 stepping example with IRQs and maskisr;
- Clarifications re adaptive clocking: not all ARMs do it, and
explain it a bit better.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Add a NOR flash mechanism where erase_address ranges can be padded
out to sector boundaries, triggering a diagnostic:
> flash erase_address 0x0001f980 16
address range 0x0001f980 .. 0x0001f98f is not sector-aligned
Command handler execution failed
in procedure 'flash' called at file "command.c", line 647
called at file "command.c", line 361
>
> flash erase_address pad 0x0001f980 16
Adding extra erase range, 0x0001f800 to 0x0001f97f
Adding extra erase range, 0x0001f990 to 0x0001fbff
erased address 0x0001f980 (length 16) in 0.095975s (0.163 kb/s)
>
This addresses what would otherwise be something of a functional
regression. An earlier version of the interface had a dangerous
problem: it would silently erase data outside the range it was
told to erase. Fixing that bug turned up some folk who relied on
that unsafe behavior. (The classic problem with interface bugs!)
Now they can get that behavior again. If they really need it,
just specify "pad".
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Based on notes from Tomek Cedro <tomek.cedro@gmail.com> and
Steve Franks <bahamasfranks@gmail.com>.
In the User's Guide, sort the list of operating systems reported
through Tcl with $ocd_HOSTOS ... and include FreeBSD.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The "parport_port" commands generally don't *require* a port_number;
they're of the "apply any parameter, then print result" variety. Update
the User's Guide accordingly.
Some of those commands are intended to be write-once: parport_port,
and parport_cable. Say so.
Use proper EBNF for the parport_write_on_exit parameter.
Parport address 0xc8b8 is evidently mutant. Say so in the "parport.cfg"
file, to avoid breaking anyone with that mutant config. But update the
User's Guide to include a sane example for the LP2 port.
Finally document the "presto_serial" command.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Make "usage" messages use the same EBNF as the User's Guide;
no angle brackets. Improve and correct various helptexts.
Don't use "&function"; a function's name is its address.
Remove a couple instances of pointless whitespace; shrink a
few overlong lines; fix some bad indents.
Add TODO list entry re full support for NAND/NOR bank names.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Make "usage" messages use the same EBNF as the User's Guide;
no angle brackets. Improve and correct various helptexts.
Specifically for the port commands, clarify that the number
is optional, and omitting it causes the current number to be
displayed.
Don't use "&function"; a function's name is its address.
Remove a couple instances of pointless whitespace; shrink a
few overlong lines.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Usage messages should use the same EBNF as the User's Guide;
no angle brackets. Be more complete too ... some params were
missing. Improve and correct various helptexts.
Make user's guide refer to the NAND "driver" name, not the
controller name; that's a bit more precise.
Don't use "&function"; its name is its address. Line up struct
initializers properly. Remove some blank lines.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Update/bugfix the "hello" example; emphasize using EBNF syntax,
matching the User's Guide. Correct the Texinfo style guide to
say EBNF, not BNF.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The issues is on Win32, which ignores case in filesystem
and thus doesn't tolerate the quilt "patches" directory.
Rename, and add "patches" to .gitignore so that developers
can choose to use quilt for local patch management.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Usage syntax messages have the same EBNF as the User's Guide;
there should be no angle brackets in either place.
Fix the User's Guide to say where the magic CP15 bits are defined;
and add comments in case someone provides mcr/mrc methods.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Deprecate the "pass an instruction opcode" flavor of cp15
access in favor of the "arm mcr ..." and "arm mrc ..."
commands, which offer fewer ways to break things.
Use the same EBNF syntax in the code as for the user's guide.
Update User's Guide to say where to find those magic values
(which table in the ARM920 TRM).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Deprecate the "pass an instruction opcode" flavor of cp15 access
in favor of the "arm mcr ..." and "arm mrc ..." commands, which
offer fewer ways to break things.
Use the same EBNF syntax in the code as for the user's guide.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Usage syntax messages have the same EBNF as the User's Guide;
there should be no angle brackets in either place.
Uupdate some helptext to be more accurate.
Fix the User's Guide in a few places to be more consistent (mostly
to use brackets not parentheses) and to recognize that parameter may
be entirely optional (in which case the command just displays output,
and changes nothing). Also reference NXP, not Philips, for LPC chips.
Don't use "&function"; functions are like arrays, their address
is their name.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Provide helptext which was sometimes missing; update some of it
to be more accurate.
Usage syntax messages have the same EBNF as the User's Guide;
there should be no angle brackets in either place.
Fix the User's Guide in a few places to be more consistent (mostly
to use brackets not parentheses) and to recognize that parameter may
be entirely optional (in which case the command just displays output,
and changes nothing). Also reference NXP, not Philips, for LPC chips.
Don't use "&function"; functions are like arrays, their address
is their name. Shrink some overlong lines.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Provide helptext which was sometimes missing; update some of it
to be more accurate.
Usage syntax messages have the same EBNF as the User's Guide;
there should be no angle brackets in either place.
Don't use "&function"; functions are like arrays, their address
is their name. Shrink some overlong lines, remove some empties.
Add a couple comments about things that should change: those
extra TCK cycles for MEM-AP reads are in the wrong place (that
might explain some problems we've seen); the DAP command tables
should be shared, not copied.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Most commands are usable only at runtime; so don't bother saying
that, it's noise. Moreover, tokens like EXEC are cryptic. Be
more clear: highlight only the commands which may (also) be used
during the config stage, thus matching the docs more closely.
There are
- Configuration commands (per documentation)
- And also some commands that valid at *any* time.
Update the docs to note that "help" now shows this mode info.
This also highlighted a few mistakes in command configuration,
mostly commands listed as "valid at any time" which shouldn't
have been. This just fixes ones I noted when sanity testing.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Remove useless space/tab at end of lines.
Remove spaces in indentation and replace with tab.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Most of this patch updates documentation and comments for various
Luminary boards, supporting two bug fixes by helping to make sense
of the current mess:
- Recent rev C lm3s811 eval boards didn't work. They must use
the ICDI layout, which sets up some signals that the older
boards didn't need. This is actually safe and appropriate
for *all* recent boards ... so just make "luminary.cfg" use
the ICDI layout.
- "luminary-lm3s811.cfg", was previously unusable! No VID/PID;
and the wrong vendor string. Make it work, but reserve it
for older boards where the ICDI layout is wrong.
- Default the LM3748 eval board to "luminary.cfg", like the
other boards. If someone uses an external JTAG adapter, all
boards will use the same workaround (override that default).
The difference between the two FT2232 layouts is that eventually
the EVB layout will fail cleanly when asked to enable SWO trace,
but the ICDI layout will as cleanly be able to enable it. Folk
using "luminary.cfg" with Rev B boards won't see anything going
wrong until SWO support is (someday) added.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Resolve a regression when using newish automagic "write_image"
modes, by always padding to the end of affected sectors.
Also document some issues associated with those automagic options,
in the User's Guide and also some related code comments.
We might need similar padding at the *beginning* of some sectors,
but this is a minimalist fix for the problems which have currently
been reported (plus doc updates).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The 10-pin JTAG layout used with these adapters is used by
a variety of platforms including AVR.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This creates the TCL interface for configuring an AT91SAM9 NAND flash
controller and implements the necessary functions to correctly work with
a NAND flash device connected to the chip. This includes updates to the
driver list and the Makefile.am to support building the driver and also
houses the documentation update in openocd.texi.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
In conjunction with manual register setup, this lets the ETM trigger
cause entry to debug state. It should make it easier to test and
bugfix the ETM code, by enabling non-trace usage and isolating bugs
specific to thef ETM support. (One current issue being that trace
data collection using the ETB doesn't yet behave.)
For example, many ARM9 cores with an ETM should be able to implement
four more (simple) breakpoints and two more (simple) watchpoints than
the EmbeddedICE supports. Or, they should be able to support complex
breakpoints, incorporating ETM sequencer, counters, and/or subroutine
entry/exit criteria int criteria used to trigger debug entry.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This command was misplaced; it's not generic to all traceport drivers,
only the ETB supports this kind of configuration. So move it, and
update the relevant documentation.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Tweak the "scan_chain" output by removing column separators. Also
remove the "current instruction" state ... which changes constantly.
Now its style resembles the "targets" output, and can even fit on
one line in standard terminals and in the PDF docs.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Add a "-ignore-version" to "jtag newtap" which makes the IDCODE
comparison logic optionally ignore version differences.
Update the "scan_chain" command to illustrate this by showing
the "*" character instead of the (ignored) version nibble.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
When starting up, say how many hardware breakpoints and watchpoints
are available on various targets.
This makes it easier to tell GDB how many of those resources exist.
Its remote protocol currently has no way to ask OpenOCD for that
information, so it must configured by hand (or not at all).
Update the docs to mention this; remove obsolete "don't do this" info.
Presentation of GDB setup information is still a mess, but at least
it calls out the three components that need setup.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Add a brief "setup with no customization" note showing the
how easily things can work if standard OpenOCD config scripts
already exist. We've had some new users comment that this
information is needlessly hard to find, so that starting to
use OpenOCD is more difficult than it should be.
Plus describe a few other issues that come up when setting
up an OpenOCD server.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Rename the existing 'flash banks' implementation as 'flash list', and
replace the broken 'flash_banks' TCL wrapper with a new command handler.
Adds documentation for the new 'flash list' command in the user guide.
List it in the concept index, in the section about target software
changes a project might want to consider, and in the section about
debug messaging.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Semihosting enables code running on an ARM target to use the
I/O facilities on the host computer. The target application must
be linked against a library that forwards operation requests by
using the SVC instruction that is trapped at the Supervisor Call
vector by the debugger. The "hosted" library version provided
with CodeSourcery's Sourcery G++ Lite for ARM EABI is one example.
This is currently available for ARM9 processors, but any ARM
variant should be able to support this with little additional work.
Tested using binaries compiled with Sourcery G++ Lite 2009q1-161
and ARM RVCT 3.0.
[dbrownell@users.sourceforge.net: doc tweaks, NEWS]
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This defines a "reset-assert" event and a supporting utility
routine, and documents both how targets should implement it
and how config scripts should use it. Core-specific updates
are needed to make this work.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.
Update the user guide with information on where OpenOCD expects to find
configuration files and scripts. Also fixed some minor formatting issues.
Add entry to NEWS as well.
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Remove two commands that were documented as "debug commands"
and where "you probably don't want to use this". We never
intended to support them, and at least one problem report
boiled down to using this when it shouldn't have been used.
Update the docs on the existing register commands to talk a
bit more about register access and cache behavior. (Those
debug commands existed largely to *bypass* the cache.) And
fix some minor doc goofs that snuck in with recent changes,
renaming "armv4_5" as "arm" and "arm9tdmi" as "arm9".
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>
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.
This documentation update provides an introduction to the command
handling facilities provided by command.[ch]. A primer walks the user
through the elements of a pointedly pedantic module: src/hello.c.
A summary of the API is provided in the OpenOCD Architecture section.
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>
We currently do something unusual: version codes in config.in get
updated after the release, which means that "git describe" won't
match up to development version labels. Comment that trouble spot.
We can fix this by switching away from the major/minor/micro type
release numbering, as various other projects have done. The major
numbers basically don't tend to change, and doing a good job with
micro versions is so annoying that they rarely change either.
Contrast releases to git snapshot tarballs. Mention that
releases have some quality-improvement focus, with special
non-"dev" version IDs. Explain more about version IDs,
using "openocd -v" to see them, etc;
Make release milestone info be less specific about timing,
and presume we have both a merge window and an RC stage.
Rework the release process information to match reality a
bit more closely. Reference the version.sh script (in one
place the wrong script was referenced). Bugfix branches
get special treatment, while non-bugfix releases are more
or less what *defines* being the mainline branch.
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>
Update documentation to reflect GIT methodology. Rewrite release.sh
script to use appropriate process. With this update, tools/release.sh
can be used for producing private release tags on local branches.
The documentation still needs work, but their use for v0.3.x should
help rectify the deficiences.
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 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
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