The fix is inline with the Linux coding style that forbids
assignment in if condition
Change-Id: I42a371d6adfdf3b3fb867705211c47d89776ee2a
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/85
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
Total of 5 warnings:
3x "Dead store": removed dead assignment to variable;
1x "Dereference of null pointer": this is not an error, but a
limited visibility of clang, since pointer erase_region_info
is initialized inside cfi_fixup_non_cfi();
1x "Branch condition evaluates to a garbage value":
this is a real coding bug that could issue SIGSEGV, since
"goto cleanup" can be executed before initialization
of "source".
Change-Id: Id3c323c82bb15cbd3bb8fc04b23541f11145f109
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/84
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
This should silence a warning.
Change-Id: Id91a9ebacae836083b1db2654a8e7bf24b2300e9
Signed-off-by: Edgar Grimberg <edgar.grimberg@gmail.com>
Reviewed-on: http://openocd.zylin.com/52
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
Perhaps we could do one better and propagate the error?
Change-Id: Idc45f516c26f09de4ee01fe05e8d3475f4b80db3
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Reviewed-on: http://openocd.zylin.com/43
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
may be used uninitialized in this function [-Werror=uninitialized]
Change-Id: Ida2cf8efe4e7da6fd9f669b806a20894563ac3d4
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Reviewed-on: http://openocd.zylin.com/49
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
Fix a few errors with set and unused variables detected by GCC 4.7.0
Change-Id: I59b748e18e514ee9f0cde7883b4ed5116198bd4a
Signed-off-by: Freddie Chopin <freddie.chopin@gmail.com>
Reviewed-on: http://openocd.zylin.com/36
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The Toshiba TMPA900 series (TMPA900/901) only has internal RAM regions
RAM-0 (16kB) and RAM-1 (8kB) which we can use as working area.
This is probably a copy-paste error from tmpa910.cfg, which has the
correct values and sizes for the TMPA910 series (TMPA910/911/912/913):
there are RAM-0, RAM-1, and RAM-2 (each 16kB).
Also, change "built-in RAM" to "internal RAM" to match what the
datasheet uses.
Change-Id: I993cd6b7fadc28cf34e5cc18426bb2bb42597670
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Reviewed-on: http://openocd.zylin.com/34
Tested-by: jenkins
Reviewed-by: Peter Stuge <peter@stuge.se>
The code in xscale_receive() that tries to skip invalid reads (i.e.
reads that don't have the DBG_SR[0] 'valid' bit set) seems to be
wrong, as it only looks at the first word's valid flag rather than
each word's own valid flag. Am I reading the code correctly? If so,
the attached patch should fix it.
If this looks correct, I'll generate a proper patch and commit message.
Matt
Change-Id: I74ebe2ad7a36d340a9dd3b8487578b6ea7f3cf1e
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Reviewed-on: http://openocd.zylin.com/32
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
Using the ICEPick reset seems to allow the processor to be halted sooner
and the halt on gdb connection makes the connect process more robust.
Change-Id: I0586f6e6becc60a729030509ef58907a19d545ec
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/23
Tested-by: Øyvind Harboe <oyvindharboe@gmail.com>
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
This sets up simple functions that can later be used to provide additional
ICEPick Operations.
Change-Id: I313b8679267696fad87d23f3692963e513f2fe21
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/22
Tested-by: Øyvind Harboe <oyvindharboe@gmail.com>
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
by immediately polling again when we have received a message from
the target instead of waiting 100ms, we can hope for much better
performance. More than 100x? :-)
Change-Id: Ieaf0c6c8b6e5addc482895670ffbf9a743e07a29
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Reviewed-on: http://openocd.zylin.com/27
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
Tested-by: Øyvind Harboe <oyvindharboe@gmail.com>
1) Add a couple more steps when setting up the Gerrit account.
Change-Id: I5d81feac4650d4d28653d14cfc0baf14270424c1
Signed-off-by: Jim Norris <u17263@att.net>
Reviewed-on: http://openocd.zylin.com/28
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: Peter Stuge <peter@stuge.se>
The DLP Design DLP-USB1232H UART/SPI/JTAG module is based on an FTDI FT2232H
chip. Among other things, it can used as JTAG programmer if connected to
the JTAG target properly. I have successfully wired the module to an
Olimex STM32-H103 eval board and flashed a firmware onto that using OpenOCD.
The setup details and schematics are documented at:
http://randomprojects.org/wiki/DLP-USB1232H_and_OpenOCD_based_JTAG_adapter
Change-Id: I5eb9255a61eeece233009bee77d7dc3b5d1afb8b
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Reviewed-on: http://openocd.zylin.com/20
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Tested-by: Spencer Oliver <spen@spen-soft.co.uk>
This is a Toshiba TMPA900CMXBG (ARM9) based SO-DIMM CPU module with 64MB
DDR SDRAM, 256MB NAND flash, and on-board Ethernet.
The board file provides a tonga2_init function which sets up the
PLL/clocks and memory (SDRAM and SRAM), which allows writing a boot-loader
into RAM via JTAG.
Change-Id: I60522b97997bdf50e1f25aebab910d93a98522fb
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Reviewed-on: http://openocd.zylin.com/19
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Tested-by: Spencer Oliver <spen@spen-soft.co.uk>
Change-Id: I1453f4f3dc0add529da20577e38b8b82d7d00366
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Reviewed-on: http://openocd.zylin.com/18
Reviewed-by: Alex Austin <alex.austin@spectrumdsi.com>
Tested-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Let the target algorithm be running in the background and buffer data
continuously through a FIFO. This reduces or removes the effect of latency
because only a very small number of queue executions needs to be done per
buffer fill. Previously, the many repeated target state changes, register
accesses (really inefficient) and algorithm uploads caused the flash
programming to be latency bound in many cases. Now it should scale better
with increased throughput.
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Access the different flash banks' registers using a bank specific register
base and a register specific offset. This is equivalent but feels more
natural.
Some accesses were discovered that maybe should not be hard coded to bank0
registers. Add a note about that.
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Split armv7m_run_algorithm into two pieces and use them to reimplement it.
The arch_info parameter is used to keep context between the two calls, so
both calls must refer to the same armv7m_algorithm struct. Ugly but works
for a proof-of-concept.
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
On supported targets, this may be used to start a long running algorithm in
the background so the target may be interacted with during execution and
later wait for its completion.
The most obvious use case is a double buffered flash algorithm that can
upload the next block of data while the algorithm is flashing the current.
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
