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>
Gumstix Verdex is a PXA270-based series of computer-on-modules. This
configuration file is based off the voipac.cfg configuration with
a different flash memory configuration. This has been tested flyswatter
adapter to reflash a Gumstix Verdex XL6P board.
The missing value for ES1.2 silicon revision is mentioned in
sprugn4m.pdf, and the recent TI Beagleboard XM is powered by it,
so let support the revision.
Target events are added to get better gdb support. The run
algorithm functionality are implemented to support feature
fast flash write functionality. The new r/w buffer api is now
used to support the special memory address handling. The output
of the md command was fixed.
Most serial adaptors are identified by udev with SUBSYSTEM=tty and
without DEVTYPE. This patch fix udev rules to work with any listed
tty-based adaptor. It has been tested with a FTDI-based Bus Pirate.
Signed-off-by: Luca Bruno <lucab@debian.org>
This is a proof of concept to get access to the debug port of a
secured kinetis cpu. On full flash erase the cpu is automatically
secured and the debug port is not accessible.
To get this to work the srst line is needed and the necessary
configuration should be added to the configuration file.
The driver sends ascii encoded bitbang commands over unix sockets or TCP to
another process. This driver is useful for debugging software running on
processors which are being simulated.
Karl Kurbjun
Attila Kinali
Øyvind Harboe
Jim Norris
Spencer Oliver
Spencer Oliver
Uwe Hermann
Michel Jaouen
Peter Stuge
Andreas Fritiofson
Simon Barner
Eugeniy Meshcheryakov
Clément Burin des Roziers
Ash Charles
Steve Bennett
Vladimir Zapolskiy
Mathias K
Luca Bruno
Uwe Bonnes
Richard Uhler
Martin Schmölzer
Rodrigo L. Rosa