Use "git revert <commit>" to revert this commit, then build and
repair and post patch to the mailing list.
Warnings generated with:
nios2-elf-gcc (GCC) 3.4.6 (Altera Nios II 9.1 b222)
openocd/src/target/dsp5680xx.c: In function 'eonce_rx_upper_data':
openocd/src/target/dsp5680xx.c:252: warning: cast increases required
alignment of target type
openocd/src/target/dsp5680xx.c: In function 'eonce_rx_lower_data':
openocd/src/target/dsp5680xx.c:268: warning: cast increases required
alignment of target type
openocd/src/target/dsp5680xx.c: In function 'eonce_pc_store':
openocd/src/target/dsp5680xx.c:508: warning: dereferencing type-punned
pointer will break strict-aliasing rules
openocd/src/target/dsp5680xx.c: In function 'dsp5680xx_read':
openocd/src/target/dsp5680xx.c:736: warning: cast increases required
alignment of target type
openocd/src/target/dsp5680xx.c:737: warning: cast increases required
alignment of target type
openocd/src/target/dsp5680xx.c: In function 'dsp5680xx_write_8':
openocd/src/target/dsp5680xx.c:823: warning: cast increases required
alignment of target type
openocd/src/target/dsp5680xx.c: In function 'dsp5680xx_write':
openocd/src/target/dsp5680xx.c:938: warning: cast increases required
alignment of target type
openocd/src/target/dsp5680xx.c:941: warning: cast increases required
alignment of target type
openocd/src/target/dsp5680xx.c: In function 'dsp5680xx_f_wr':
openocd/src/target/dsp5680xx.c:1355: warning: cast increases required
alignment of target type
- works on Cortex-M3 with ThreadX and FreeRTOS
Compared to original patch a few nits were fixed:
- remove stricmp usage
- unsigned compare fix
- printf formatting fixes
- fixed a bug with overrunning a memory buffer allocated with malloc.
Really a Cortex-A specific option, but there is no
system in place to support target specific options
currently and there has been no need for such a system
until now.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Fix a bunch of typos.
Most are in code comments, so nothing should break. UNKOWN_COMMAND and
CMD_UNKOWN are not used elsewhere, so correcting the spelling should
also not break anything.
ARM Cortex-A9 multi-core chips expose a single TAP/DAP which connects
to both cores. The '-coreid' option selects which core the target
should connect to.
Note that at present, OpenOCD can connect to either core, but not both
simulatenously, until ADI contexts can be shared.
Signed-off-by: Aaron Carroll <aaronc@cse.unsw.edu.au>
We only use the struct working_area member 'free' as a
true/false type so might as well use a bool data type.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
I received a number of "-Wshadow" related warnings (treated as errors) while
trying to build on OS X Leopard. In addition, there were two miscellaneous
other warnings in the flash drivers. Attached are two patches which correct
these issues and the commit messages to accompany them.
My system has the following configuration (taken from uname -a):
Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_I386 i386
=== Werror_patch.txt Commit Message ===
compilation: fixes for -Wshadow warnings on OS X
These changes fix -Wshadow compilation warnings on OS X 10.5.8
Compiled with the following configure command:
../configure --prefix=/usr/local --enable-maintainer-mode --enable-jlink
--enable-ft2232_libftdi
=== flash_patch.txt Commit Message ===
compilation: fixes for flash driver warnings on OS X
These changes fix two compilation warnings on OS X 10.5.8:
../../../../src/flash/nor/at91sam3.c:2767: warning: redundant redeclaration
of 'at91sam3_flash'
../../../../src/flash/nor/at91sam3.c:101: warning: previous declaration of
'at91sam3_flash' was here
and
../../../../src/flash/nor/stmsmi.c:205: warning: format not a string literal
and no format arguments
Compiled with the following configure command:
../configure --prefix=/usr/local --enable-maintainer-mode --enable-jlink
--enable-ft2232_libftdi
===
Andrew
error numbers are only reported at DEBUG log levels and
used internally, they are not part of the user interface.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
it's a lie that is somewhere in the vicinity of the
truth. Certainly 64MHz confuses gprof and produces
zero output and no error messages.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
So far most of the people have been using existing ARM966E in the
place of ARM946E, because they have practically the same scan chains.
However, ARM946E has caches, which further complicates JATG handling
via scan-chain. this was preventing single-stepping for ARM946E when
SW breakpoints are used.
This patch thus introduces :
1) Correct cache handling on memory write
2) Possibility to flush whole cache and turn it off during debug, or
just to flush affected lines (faster and better)
3) Correct SW breakpoint handling and correct single-stepping
4) Corrects the bug on CP15 read and write, so CP15 values
are now correctly R/W
Collect variable definitions.
Report syntax error to command dispatcher.
Propagate error when unable to open file.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
committed so as to ease cooperation and to let it be improved
over time.
So far it supports:
- halt/resume
- registers inspection
- memory inspection/modification
I'm still getting up to speed with OpenOCD internals and AVR32 so code is a little
bit messy and I'd appreciate any feedback.
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>
back-off algorithm for polling. Double polling
interval up to 5000ms when it fails.
when polling succeeds, reset backoff.
This avoids flooding logs(as much) when working
with conditions where the target polling will fail.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
It is useful to know that the printed errors are *all* the
errors there were.
Added missing error handling(found by inspection).
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
failure to write to memory was not propagated.
This is an interesting case of broken error handling:
with exceptions we wouldn't have had this at all,
and I also wonder if there is a GCC option to warn
about these kinds of potential bugs.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Change download rate messages about kibibytes from "kb/s" to "KiB/s" units.
See: http://en.wikipedia.org/wiki/Data_rate_units
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
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>
Various commands, e.g. "arm mcr xxxx" would fail if invoked upon startup
since it there was no command context defined for the jim interpreter
in that case.
A Jim interpreter is now associated with a command context(telnet,
gdb server's) or the default global command context.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
target memory allocation can be implemented not to show
bogus error messages.
E.g. when trying a big allocation first and then a
smaller one if that fails.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
I'm not sure what caused this significant character to get deleted.
it may be related to intermittent Editor or terminal flakes I've
been seeing lately (sigh). This fix is trivial.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Fixing one bug can easily uncover another .... in this case,
making sure that we properly invalidate some cached NOR state when
resuming arbitrary target code turned up an issue when the code
wasn't quite arbitrary (and we couldn't know that, but some parts
of OpenOCD assumed the cache would not be invalidated.
Specifically: some flash drivers (like CFI) update that state in loops
with downloaded algorithms, thus invalidating the state as it's probed.
+ Add a new target state flag, to record whether the target is
running downloaded algorithm code.
+ Use that flag to add a special case: "trust" downloaded algorithms
not to corrupt that cached state, bypassing cache invalidation.
Also update some of the documentation to stipulate that this flavor of
trustworthiness is now *required* ... not just a fortuitous acident.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
For some reason there are *two* schemes for interposing logic into
the run_algorithm() code path... One is a standard procedural wapper
around the target method invocation.
the other (superfluous) one hacked the method table by splicing
a second procedural wrapper into the method table. Remove it:
* Rename its slightly-more-featureful wrapper so it becomes
the standard procedural wrapper, leaving its added logic
(where it should have been in the first place.
Also add a paranoia check, to report targets that don't
support algorithms without traversing a NULL pointer, and
tweak its code structure a bit so it's easier to modify.
* Get rid of the superfluous/conusing method table hacks.
This is a net simplification, making it simpler to analyse what's
going on, and then interpose logic . ... by ensuring there's only one
natural place for it to live.
------------
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
I don't know when "poll off" broke, but "poll off" didn't
stop background polling of target. The polling status flag
simply wasn't checked in the handle_target timer callback.
All target polling(including power/reset state) is now stopped
upon "poll off".
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
The NOR infrastructure caches some per-sector state, but
it's not used much ... because the cache is not trustworthy.
This patch addresses one part of that problem, by ensuring
that state cached by NOR drivers gets invalidated once we
resume the target -- since targets may then modify sectors.
Now if we see sector protection or erase status marked as
anything other than "unknown", we should be able to rely
on that as being accurate. (That is ... if we assume the
drivers initialize and update this state correctly.)
Another part of that problem is that the cached state isn't
much used (being unreliable, it would have been unsafe).
Those issues can be addressed in later patches.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Add doxygen for target_resume() ... referencing the still-unresolved
confusion about what the "debug_execution" parameter means (not all
CPU support code acts the same).
The 'handle_breakpoints" param seems to have resolved the main issue
with its semantics, but it wasn't part of the function spec before.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Stefan Mahr
Øyvind Harboe
Rodrigo L. Rosa
Michel Jaouen
Broadcom Corporation (Evan Hunter)
Mathias K
Uwe Hermann
Aaron Carroll
Spencer Oliver
Andrew MacIsaac
ddraskovic
Antonio Borneo
Oleksandr Tymoshenko
Edgar Grimberg
Jon Povey
David Brownell