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>
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>
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>
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>
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>