this fn has something to do with the queue, which it does not as such.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2050 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Remove broken whitespace ... mostly at end of line, but
also in some cases blocks of inappropriate empty lines.
And spell "comamnd" right. :)
git-svn-id: svn://svn.berlios.de/openocd/trunk@1972 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- use continuations to break long lines of variable assignments
- makes these variables more patch-friendly and conform to style guide
git-svn-id: svn://svn.berlios.de/openocd/trunk@1970 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- replaces all calls to target->type->bulk_write_memory.
- add documentation in target_s to warn not to invoke callback directly.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1963 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- replaces all calls to target->type->run_algorithm.
- add documentation in target_s to warn not to invoke callback directly.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1961 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- replaces all calls to target->type->write_memory.
- add documentation in target_s to warn not to invoke callback directly.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1960 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- replaces all calls to target->type->read_memory.
- add documentation in target_s to warn not to invoke callback directly.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1959 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- provides low-level information about each flash API interface,
- gives driver authors some documentation about the driver interface,
- updated extensively from the original patch provided by Duane Ellis.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1942 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Fix a bug that joined us at the last minute, when an efficient
alloca() call got swapped out for a more portable malloc().
Also log one error, to give a clue in case it appears "in the wild".
git-svn-id: svn://svn.berlios.de/openocd/trunk@1907 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Update two oddball NAND commands to work with {offset, length}
instead of block numbers, matching the other commands as well
as usage in U-Boot and the Linux-MTD utilities.
Document them accordingly. Update the single in-tree use of
those commands (sheevaplug).
ALSO:
(a) Document the current 2 GByte/chip ceiling for NAND chipsize.
(32 bit offset/length values can't represent 4 GBytes.) Maybe
after the upcoming release, the code can switch to 64-bits.
(b) The "nand check_bad_blocks" should report "bad" blocks. They
are not "invalid" blocks; they're "bad" ones.
(c) Tweak the "nand info" command to handle the "no arguments"
case sanely (show everything, instead of showing garbage) and
not listing the blocksize in hex kbytes (duh).
git-svn-id: svn://svn.berlios.de/openocd/trunk@1904 b42882b7-edfa-0310-969c-e2dbd0fdcd60
NAND support for DaVinci-family drivers, with HW ECC support.
Declare the NAND chip on the DM355 EVM board.
Currently tested on DM355 for Linux interop using the standard
large page (2KB) chip in the EVM socket; "hwecc1" and "hwecc4"
work fine. (Using hwecc4 relies on patches that haven't quite
made it through the Linux-MTD bottlenecks yet.)
Not yet tested: 1-bit on small-page (although it's hard to see
how that could fail); 4-bit on small page (picky layout issues);
the "hwecc_infix" mode (primarily for older boot ROMs; testing
there is blocked on having new bootloader code).
git-svn-id: svn://svn.berlios.de/openocd/trunk@1903 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Remove un-implemented and dubious "nand copy" command.
Doing this efficiently would mean doing the copying on
the target CPU, instead of back and forth through JTAG.
If anyone ever needs this functionality, that's what
they should implement.
Also, update on-line "help" for "nand dump" to display
its two optional flags; and for "nand write" to display
a recently added flag.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1883 b42882b7-edfa-0310-969c-e2dbd0fdcd60
the key command_*() helper functions, fixng the bugs that turned up.
Several of these bugs were from misuse of PRIi64; that's for 64-bit
integers, NOT for "long long" or "u64" (which work best with %lld).
git-svn-id: svn://svn.berlios.de/openocd/trunk@1873 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Add libtoolize step too bootstrap script; creates ltmain.sh script.
- Add AC_PROG_LIBTOOL to configure.in to add libtool support to build.
- Change Makefile.am library rules from static (_a) to libtool (_la).
- Install libopenocd.{la,so,a} in $(libdir); update openocd link rules.
- Extend MAINTAINERCLEANFILES in top-level Makefile.am to remove ltmain.sh.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1695 b42882b7-edfa-0310-969c-e2dbd0fdcd60
already required autoconf 2.59 (circa 2006), so there is no reason to
support versions of automake older than 1.6 (circa 2002).
The first part of this patch upgrades the configure.in script:
1. Use current calling conventions for the AC_INIT and
AM_INIT_AUTOMAKE macros, bringing their usage up-to-date with
the version of autoconf already specified by AC_PREREQ.
2. Add AC_CONFIG_SRCDIR macro, required by new version of AC_INIT.
3. Automatically enable all of automake's warnings except Makefile
portability (which OpenOCD violates by using GNU make's $(wildcard)).
[[ While automake has its own -Werror option, I did not enabled it
due to existing warnings. ]]
4. Add the missing AM_PROG_C_O check, required by the build rules for
openocd.o in src/Makefile.am.
5. Adjust version number to show progress toward the next release.
6. Include a bug reporting e-mail address to direct users to this list.
This patch makes the following adjustments to the Makefile.am files:
1. Update AUTOMAKE_OPTIONS to require automake version 1.6
2. Rewrite all deprecated INCLUDES assignments as AM_CPPFLAGS
3. Clean-up all AM_CPPFLAGS declarations to be patch-friendly.
4. Remove vestigial references to $(all_includes)
5. Remove erroneous references to @CPPFLAGS@ (only use AM_CPPFLAGS)
6. Remove unused -I and -D directives in helper/, flash/, target/
git-svn-id: svn://svn.berlios.de/openocd/trunk@1591 b42882b7-edfa-0310-969c-e2dbd0fdcd60