An alternative approach to show how much cleaner the pure pkg-config
way is.
This changes the discovery procedures for libusb-1.0 and libusb-0.1,
making them depend on pkg-config being properly installed and
configured, including the necessary build host configuration for the
cross-builds (see
http://www.flameeyes.eu/autotools-mythbuster/pkgconfig/cross-compiling.html)
It should make it possible to compile OpenOCD without changes and
extra effort on GNU/Linux, FreeBSD users would need to supply a .pc
file for their libusb implementation or add LIBUSB1_LIBS and
LIBUSB1_CFLAGS to the configure environment.
Change-Id: I826e378dd1e0d101a549a573b2c63212a7e00b64
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1467
Reviewed-by: Xiaofan <xiaofanc@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Tested-by: Spencer Oliver <spen@spen-soft.co.uk>
.soft_reset_halt is not necessary for nds32 target.
Remove the dependency.
Change-Id: Ic3b126d6c7eb995583a661b762627e736222fcaa
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1612
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
As GDB uses file-I/O protocol to access memory, use DMA to access
if no DCache. This commit improves the performance of Andes
Virtual Hosting.
Change-Id: I36bb2154b9f497fc4237625836cf8c7115330a60
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1580
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Modify handle_nds32_memory_access_command: do not use DCache
setting to block user's setting.
Change-Id: I2d33f893773e2a2e3e2f26edde5938ef5902609d
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1579
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
If multiple read watchpoints are hit at the same time, report
any one of these hit watchpoints.
Change-Id: I8d4439aa80e4b62bb7d48bbdc0450920e2008a2e
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1576
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Do not turn on/off polling as leave/enter debug mode.
Enable polling after gdb attached, and disable polling
after gdb detached.
Change-Id: Id64459b86f44937af7ea5ccfe2cd13e31732eecf
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1574
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
1. gprof uses 2-bytes as minimum bucket size.
2. As user wants to use gprof --sum to summarize multiple
profiling data files, the range MUST be the same.
Add new arguments to specify profiling range.
Change-Id: Ie7e6afa6a4d82250e2d194a0eed2b428c1479ea1
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1572
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Profiling could be target-specific. Add .profiling interface
to target_type.
Change-Id: Ic0eea9db742971db1350a474fbbb5ed24565922b
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1571
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
I do not know what is the reasonable number of buckets.
If there are enough buckets, the result will be accurate.
I propose increase the maximum number of buckets to 128K.
If the size of program text section is less than 256KB, every
two bytes will be occupied by one buckets.
(The minimum size of one buckets is 2 bytes in gprof implementation.)
Change-Id: If9147743cefdc36f40f21e6dc73b9b28f28c9e1e
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1608
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
1. high_pc should be (maximum sample + 1) (Refer to gprof source code)
2. bucket index should be
sample offset
--------------- x (number of bucket)
sample range
For example, if minimum sample is 0 and maximum sample is 5
and the number of bucket is 3.
a = sampled_address - 0
b = 3
c = 6
(a, b, c refer to source code variables)
sampled_address = 0, => a = 0, => bucket_index = 0
sampled_address = 1, => a = 1, => bucket_index = 0
sampled_address = 2, => a = 2, => bucket_index = 1
sampled_address = 3, => a = 3, => bucket_index = 1
sampled_address = 4, => a = 4, => bucket_index = 2
sampled_address = 5, => a = 5, => bucket_index = 2
Change-Id: Ia9fa0e4d9c7183e3e9d7ceaf73e63729f07aa2ce
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1607
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Change variable name 'length' to 'numBuckets'. It is more readable.
Change-Id: I913cba0746f887adf6da401a46cd5e9ea88d2c6d
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1606
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
In GDB connected to OpenOCD there is a command "monitor gdb_sync" which makes
next stepi command to be ignored while GDB still will get an updated target
state. This command sets gdb_connection->sync field to true to notify that stepi
should be ignored. This field is set to true for all new connection and is set
to false after first "continue" command. However if first resume command is
stepi/nexti then it will be ignored and result will confuse GDB client, it will
report that target received signal SIGINT. This patch sets this field to false
for new connections, thus stepi/nexti will work properly when it is a first
resume command.
Change-Id: I7c9ebd69c3dc35f3e316041aa99f4e9d3425c0b6
Signed-off-by: Anton Kolesov <akolesov@synopsys.com>
Reviewed-on: http://openocd.zylin.com/1587
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Keep the promise and ensure there're at least 3 bytes available after
the current position.
This eliminates the errors reported by Valgrind.
Change-Id: I1d0640e904c750eed808b2b4caf419b4d7619845
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1615
Tested-by: jenkins
Reviewed-by: Peter Stuge <peter@stuge.se>
Rewrite the target_*_buffer_default to generate as large accesses as
possible while maintaining natural alignment.
These versions are easy to extend to generate 8-byte accesses to support
64-bit targets, although it requires some conformity from all target
implementations (i.e. they need to refuse unsupported access sizes with
some defined error code, so we can try again with a smaller one).
Change-Id: I00ddcbb1d2fd33f9f8b99cb448cc93505a2421fc
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1221
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The only remaining user is arm7_9 so remove it from the target API and add
it to struct arm7_9_common to support all its variants with minimal
changes. Many of the variants are likely not correct in the cache/mmu
handling when the bulk write is triggered. This patch does nothing to
change that, except for arm946e, where it was easier to do what might be
the right thing.
Change-Id: Ie73ac07507ff0936fefdb90760046cc8810ed182
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1220
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
remove clang warning - "Argument to free() is the address of a global
variable, which is not memory allocated by malloc()".
Change-Id: I015273eafc9644207684b363434c6ae8149bfcde
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1613
Tested-by: jenkins
We already set cpsr in armv7m_build_reg_cache, so lets use it for all other
accesses to this field.
Change-Id: I19b3b21ecf1571bbea12e1be664845e6544f6fa1
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1539
Tested-by: jenkins
Make sure the target support target requests before we enable any receivers.
Change-Id: I8ce42922eaff76fb5e7a114da716f2a6585a6ab5
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1536
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Let the default handler issue an unsupported warning rather than using
empty handler routines that may/may not issue a unsupported warning.
Change-Id: Iafe3e45146981a4cfae39771c3ab7370ac86da48
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1535
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-by: Hsiangkai Wang <hsiangkai@gmail.com>
Adds a flash driver for Nuvoton MINI51, MINI52 and MINI54 microcontrollers.
At the moment, it only supports the erase and write operations.
These microcontrollers have a 4 / 8 / 16 KB APROM for application code and a
2 KB LDROM for bootloaders. When the MCU has booted off the APROM, the LDROM
isn't mapped in memory but can be programmed, and the other way around.
This means that the ARM core is typically rebooted for programming. After a
successful write or erase operation, it is rebooted again, using the initial
boot source.
This driver only supports programming the APROM.
This driver is a pure JTAG implementation, it doesn't use any SRAM.
I've tested it on a MINI54ZAN microcontroller using an ST-LINK/V2. With the
microcontroller running at the default clock frequency of 22.1184 MHz, speed
seems to be around 1.1 KB/s.
Change-Id: I180889c55af9fb5614cd99a953b755baba14288a
Signed-off-by: Cosmin Gorgovan <cosmin@linux-geek.org>
Reviewed-on: http://openocd.zylin.com/1546
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This patch adds a driver for the jtag_vpi server [1]. This server is
now part of the ORPSoC version 3 (OpenRISC Reference Platform SoC).
The jtag_vpi server provides an interface between OpenOCD and a simulated
core.
[1] http://github.com/fjullien/jtag_vpi
Change-Id: I717b72cace4845f66c878581345074f99002e21a
Signed-off-by: Franck Jullien <franck.jullien@gmail.com>
Reviewed-on: http://openocd.zylin.com/1609
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Not all devices with devce id 0x419 have dual flash banks, only those
with > 1024kB.
Change-Id: I197d2b87df7599cd0837e25648af48439f2f1e50
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1544
Tested-by: jenkins
If target does not support semi-hosting function, it has
no need to provide .get_gdb_fileio_info callback. OpenOCD
will use default function target_get_gdb_fileio_info_default.
The default function just return ERROR_FAIL and gdb_server
will treat every halted condition as normal halted and
return "Txx" to gdb.
Change-Id: I9ddb2be3a1145eae2ef5b712bdea89eb2e0fbc20
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1586
Tested-by: jenkins
Reviewed-by: Nemui Trinomius <nemuisan_kawausogasuki@live.jp>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
It appears that on some host USB configurations(2012 MacBook Air)
multiple restarts of openocd tool cause the FW on STLINKv2 dongle to
go into a weird state in which it will no longer respond to
STLINK_GET_VERSION command. This patch adds code that, if said request
fails for the first time, attempts to reset the device and retry to
initialize it and obtain FW information one more time.
Change-Id: I7227fc972adb49d52ae700ad48ab9f66b2aaa72c
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-on: http://openocd.zylin.com/1561
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Replace 0b10 with 0x02, 0b is a GCC extension and isn't supported by
clang, for instance, so compiling on OS X will fail. No functional
changes.
Change-Id: Ie882be1563df03e7ad3da0bc9aee65a907a29549
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/1560
Tested-by: jenkins
Reviewed-by: Xiaofan <xiaofanc@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Unfortunately the Medium+ density and 0x436 devices have their F_SIZE register
at a different location: 0x1FF800CC instead of 0x1FF8004C. Fix this for
the 0x427 Medium+ devices and also the 0x436 devices. Furthermore, for
0x436 devices the flash size is reported as a 0 or 1 code rather than
the size in Kb. Please see RM0038 r8 or newer for an explanation, as
noted in the comments.
Change-Id: Ie03b1e119a61f2a854bc2ccc5f90ce3e8852e272
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/1522
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
After the target was reset we can be sure it's not running any
algorithm.
This fixes the following failure scenario:
On my STM32F103 board after I start the firmware and then stop and try
to "load" in gdb (before doing mon reset halt), I get
Error: timeout waiting for algorithm, a target reset is recommended
However, target reset doesn't help as the flag is still there ("Error:
Target is already running an algorithm"), so I have no choice but to
restart the OpenOCD process.
I'm not sure yet what exactly prevents load from working after my
firmware is initialised, most probably some interrupt is firing and my
handler produces a fault due to garbled RAM.
Change-Id: Idd977f2780a64d84800e3abd412cffc1ab6801b0
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1512
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This adds example config and flash driver for russian Cortex-M3
microcontroller model.
Run-time tested on MDR32F9Q2I evaluation board; the flash driver
should be compatible with MDR32F2x (Cortex-M0) too but I lack hardware
to test.
There're no status bits at all, the datasheets specifies some delays
for flash operations instead. All being in <100us range, they're hard
to violate with JTAG, I hope. There're also no flash identification
registers so the flash size and type has to be hardcoded into the
config.
The flashing is considerably complicated because the flash is split
into pages, and each page consists of 4 interleaved non-consecutive
"sectors" (on MDR32F9 only, MDR32F2 is single-sectored), so the
fastest way is to latch the page and sector address and then write
only the part that should go into the current page and current sector.
Performance testing results with adapter_khz 1000 and the chip running
on its default HSI 8MHz oscillator:
When working area is specified, a target helper algorithm is used:
wrote 131072 bytes from file testfile.bin in 3.698427s (34.609 KiB/s)
This can theoretically be sped up by ~1.4 times if the helper
algorithm is fed some kind of "loader instructions stream" to allow
sector-by-sector writing.
Pure JTAG implementation (when target memory area is not available)
flashes all the 128k memory in 49.5s.
Flashing "info" memory region is also implemented, but due to the
overlapping memory addresses (resulting in incorrect memory map
calculations for GDB) it can't be used at the same time, so OpenOCD
needs to be started this way: -c "set IMEMORY true" -f
target/mdr32f9q2i.cfg
It also can't be read/verified because it's not memory-mapped anywhere
ever, and OpenOCD NOR framework doesn't really allow to provide a
custom handler that would be used when verifying.
Change-Id: I80c0632da686d49856fdbf9e05d908846dd44316
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1532
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Enable reading the SWO trace output via STLinkv2 dongles that support
it.
This adds an optional initialization parameter "trace" with which the user
specifies a destination file where SWO trace output is appended as it comes in
as well as the trace module's source clock rate.
STLink will be configured for a 2MHz SWO data rate (STLink's highest
supported rate) if the source clock is > 2MHz, otherwise the source
clock is used as the data rate directly.
For example:
trace swo.log 168000000
If "trace" is specified with a usable file path, the stlink_usb driver will
attempt to configure and read SWO trace data as follows:
- on _run(), the target's TPI and TMI are configured and the STLinkv2 is told
to enable tracing. Only generic ARM TPI and TMI registers are
configured, any MCU-specific settings (ex: pin routing) are the
responsibility of the target firmware. The configuration applied is
based on the STLinkv2's capabilities (UART emulation).
- on _v2_get_status(), the trace data (if any) is fetched from the
STLink after the target status is checked and the target is found to
be running.
- on _halt(), the STLink is told to disable tracing.
When fetching trace data, the entire trace frame is written to the output file
and that data is flushed. An external tool may be used to parse the
trace data into a more human-readable format.
Tested on ARM Cortex M4F and M3 MCUs (STM32F407 and STM32L152).
Change-Id: Ic3983d46c82ba77010c23b0e18ce7b275d917f12
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/1524
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
As debugging multi-targets, every target has its own gdb connection.
If there are two connections, gdb_target_callback_event_handler will
be registered twice. Everytime event occurs, the registered callback
will be executed twice. If both targets are running, as user issues
ctrl-c in one gdb client, both connections will send "stop reply" to
GDB clients even TARGET_EVENT_GDB_HALT is caused by one of them.
The commit fix above problem as debugging multi-targets.
Change-Id: I1e12d4846927d7dcf1e3bb9aeb1affabc80df813
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1501
Tested-by: jenkins
Reviewed-by: Sergey Borshch <sb-sf@users.sourceforge.net>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Currently, there is no way to notify gdb that program has exited.
Add new target_debug_reason called DBG_REASON_EXIT to notify gdb
the condition has occured. If the debug reason is DBG_REASON_EXIT,
gdb_server will send 'W' packet to tell gdb the process has exited.
Change-Id: I7a371da292716a3e6ac4cc2c31b009a651fe047a
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1242
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The File I/O remote protocol extension allows the target to use the
host's file system and console I/O to perform various system calls.
To use the function, targets need to prepare two callback functions:
* get_gdb_finish_info: to get file I/O parameters from target
* gdb_fileio_end: pass file I/O response to target
As target is halted, gdb_server will try to get file-I/O information
from target through target_get_gdb_fileio_info(). If the callback function
returns ERROR_OK, gdb_server will initiate a file-I/O request to gdb.
After gdb finishes system call, gdb will pass response of the system call
to target through target_gdb_fileio_end() and continue to run(continue or step).
To implement the function, I add a new data structure in struct target,
called struct gdb_fileio_info, to record file I/O name and parameters.
Details refer to GDB manual "File-I/O Remote Protocol Extension"
Change-Id: I7f4d45e7c9e967b6d898dc79ba01d86bc46315d3
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1102
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
