Autotools and the current build system define HAVE_* macros only when
the corresponding feature is available, leaving them undefined otherwise.
HAVE_CAPSTONE is an exception, align it with this convention to make the
build system more consistent and slightly simpler.
Change-Id: I0b71743a687802b905e3fe1e17cad815a7febb14
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/9540
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
About why the new log level LOG_LVL_DEBUG_USB has the same value a
LOG_LVL_DEBUG_MALLOC, see the mailing list discussion starting here:
Replacing --enable-verbose-usb-comms in configure.ac
https://sourceforge.net/p/openocd/mailman/message/59215751/
Other minor fixes included here which are probably
not worth submmitting in separate patches:
- In error message "level must be between -3 and 4", increase 4 to 5.
- LOG_DEBUG_IO was passing LOG_LVL_DEBUG instead of LOG_LVL_DEBUG_IO.
Change-Id: I71440bbabe4785338c0a27562cc76fa1b7d54bf5
Signed-off-by: R. Diez <rdiez-2006@rd10.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/9432
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
On the specific fork of clang for MacOS, the compiler gets more
strict on the use of GNU folding constants, generating warnings
that halts the build of OpenOCD.
The GNU folding constants are highlighted by upstream clang only
for global variables. E.g.:
const int len = 10;
int array[len];
generates the warning on:
clang -c x.c
x.c:2:5: warning: variable length array folded to constant
array as an extension [-Wgnu-folding-constant]
int array[len];
^
Apparently only the MacOS fork generates warning for folded
constants inside a function. E.g.:
int a(int *x);
int b(void)
{
const int len = 10;
int array[len];
return a*array);
}
does not return error even forcing -Wgnu-folding-constant on clang
upstream.
Current code triggers warning on the following lines due to the
size of the array being computed from a const variable:
jtag/drivers/xds110.c:354 unsigned char data[max_data + 1];
flash/nor/dw-spi.c:950 uint8_t buffer[buffer_size];
flash/nor/dw-spi.c:980 uint8_t buffer[buffer_size];
flash/nor/dw-spi.c:1034 uint8_t buffer[buffer_size];
flash/nor/dw-spi.c:1065 uint8_t buffer[buffer_size];
flash/nor/jtagspi.c:364 uint8_t ..., write_buffer[max], ...;
flash/nor/stmqspi.c:778 char ..., output[(2 + max + 256) * 3 + 8];
flash/nor/xcf.c:392 uint8_t reference[L];
target/target.c:3303 char output[line_bytecnt * 4 + 1];
target/semihosting_common.c:1787 char buf[buf_len];
target/smp.c:59 char hex_buffer[len * 2 + 1];
target/smp.c:60 uint8_t buffer[len];
target/cortex_m.c:296 uint32_t r_vals[n_r32];
target/cortex_m.c:297 uint32_t dhcsr[n_r32];
target/x86_32_common.c:1337 char output[line_bytecnt * 4 + 1];
target/riscv/riscv.c:2377 uint8_t buffer[length];
target/xtensa/xtensa.c:536 uint8_t ops_padded[max_oplen];
While some of the const variable above could be replaced by macros,
for the majority of them I don't see such need, and the use of
const looks to me correct.
Silent the warning adding the clang flag -Wno-gnu-folding-constant.
The flag is not recognized by GCC, but it's silently ignored.
Change-Id: I1d452af115355bc4949b1616648fe6544cc48318
Reported-by: Frank Zeyda <frank.zeyda@gmail.com>
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/9431
Tested-by: jenkins
Reviewed-by: Marc Schink <dev@zapb.de>
Previously, configure.ac only checked whether glibc was available,
but other C runtime libraries like Newlib have mallinfo too.
This is a first step to remove configuration option --enable-malloc-logging
and replace it with a debug level configurable at runtime.
Change-Id: If30fc98a84158459e222fddf08043f46d6fa4112
Signed-off-by: R. Diez <rdiez-2006@rd10.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/9394
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
cJTAG OSCAN1, in lieu of 4-wire JTAG, is starting to be a configuration
option for some SiFive hardware. An FTDI-based adapter that can be
configured to drive the bidirectional pin TMSC is assumed for this
topology. Specifically, the Olimex ARM-USB-TINY-H with the ARM-JTAG-SWD
adapter, connected to a SiFive cJTAG-enabled target board is the only
known concrete topology, currently. But in theory, other FTDI based
devices that can drive a two-wire bidirectional signaling pattern could
be made to work in this scheme in the future.
These code changes are offered as a way to drive that topology. It's
translating IR/DR and JTAG traversal commands to the two-wire clocking
and signaling.
See:
- https://github.com/riscv-collab/riscv-openocd/pull/320
- https://github.com/riscv-collab/riscv-openocd/pull/736
Signed-off-by: Greg Savin <greg.savin@sifive.com>
Signed-off-by: mrv96 <mrv96@users.noreply.github.com>
Signed-off-by: Tim Newsome <tim@sifive.com>
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Change-Id: Ia1daa2c01227c4b0005be947b2bb0de81a800874
Reviewed-on: https://review.openocd.org/c/openocd/+/6981
Tested-by: jenkins
Commit ce3bf664c8 ("configure.ac: rename M4 macro 'adapter' to
prevent accidental conflicts") renames the macro as 'adapterTuple'
but since the macro name is printed in error messages, this
creates cryptic errors like:
configure: error: header sys/mman.h is required
for adapterTuple "Bitbanging on EP93xx-based SBCs".
Rename it as 'adapter_driver'. It keeps valid the purpose of the
former renaming, while keeping readable the error message.
Change-Id: Idd68270fbdf879153cd59f4cacf5036aa599b251
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Fixes: ce3bf664c8 ("configure.ac: rename M4 macro 'adapter' to prevent accidental conflicts")
Reviewed-on: https://review.openocd.org/c/openocd/+/9160
Tested-by: jenkins
The adapter's driver that require the header file sys/mman.h
should check for it and don't compile if it is not present.
Add the check for sys/mman.h in configure.ac and prevent the
build of the adapter's driver that depend on it.
Change-Id: If0a518069e8fef9b41a67b633ec20e2f142a8b14
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/9159
Tested-by: jenkins
We deprecate direct I/O support in favor of ppdev for the following
reasons:
- Linux supports ppdev since ~2.4 (released ~24 years ago) and it is
enabled by default on major distros (Ubuntu, Fedora). So it is
effectively ubiquitous
- FreeBSD provides no direct I/O support, so ppdev (ppi) is the only
viable option
- Direct I/O requires root/elevated privileges which is inadvisable
- Removing direct I/O reduces build and driver complexity and yields
a smaller, easier-to-maintain codebase
- Supporting only ppdev allows us to simplify the codebase by using
device files (e.g., /dev/parport0) instead of numeric identifiers
Windows is the only rationale to keep direct I/O, but the user base
appears minimal to nonexistent and no active contributors can test the
Windows driver.
Change-Id: Ia6d5ed6e8c5faa2a9b4919ca97c5cf9033372a64
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/9151
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
This finalizes the work that has begun to emulate v2 API
for older libgpiod versions.
It also add the required autotools/pkg-config stuff to
detect the available libgpiod version.
Change-Id: I2c3a60ce607ed9601b01d22d5d9b8af953944941
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/8226
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Create a new backend for cmsis_dap driver that allows CMSIS-DAP protocol
to run over TCP/IP instead of USB.
An example implementation of the firmware for an SWD programmer that
uses this cmsis_dap_tcp protocol can be found at the link below.
https://github.com/bkuschak/cmsis_dap_tcp_esp32
Using this cmsis_dap_tcp backend with the firmware above on an ESP32-C6
programmer and STM32F401RE target shows the following performance:
- loading 96KB image to RAM: 80 KB/sec
- dumping 96KB image from RAM: 72 KB/sec
- flashing 512KB image completes in about 13.5 seconds (including erase,
program, and verify).
Change-Id: I6e3e45016bd16ef2259561b1046788f5536b0687
Signed-off-by: Brian Kuschak <bkuschak@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8973
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
This adds general support for JTAG adapters based on the WCH CH347T and
CH347F chips.
The CH347T must be configured in mode 3 to provide both UART and JTAG
interfaces. The CH347F exposes UART and JTAG directly. Similar to FTDI
FT2232-based devices, the CH347T/F can be used for simultaneous UART and
JTAG communication.
The ch347 driver code is based on:
https://github.com/WCHSoftGroup/ch347
Bug fixes and adjustments were made to align the code with OpenOCD style
and ensure compatibility. The driver was integrated into the OpenOCD
build system.
The USB packet format was identified using public GitHub sources and
documented here:
https://www.easydevkits.com/wch-ch347-jtag-interface/
Change-Id: I5fca9dd015111e4410fea029611fdeedbb228fdb
Signed-off-by: EasyDevKits <info@easydevkits.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7937
Tested-by: jenkins
Reviewed-by: ZhiYuanNJ <871238103@qq.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
_DEBUG_USB_IO_ was not actually used anywhere.
Its last user was the old ft2232 driver removed in Nov 2016
with commit cc2d4f015f
("Remove since long deprecated ft2232 driver").
Change-Id: I1a98db7c7b03a89cc9347c0a66ec2106d2168c3f
Signed-off-by: R. Diez <rdiez-2006@rd10.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/9002
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
This change allow to use direct mapping of the JTAG interface using
Xilinx Virtual Cable (XVC) over AXI. This merges the existing XVC PCIe
code and the patch proposed by Jeremy Garff
(https://review.openocd.org/c/openocd/+/6594).
This is useful when using on a Zynq/ZynqMP/uBlaze host with direct
access to the debug bridge over AXI. You can then use the debug bridge
Xilinx IP (AXIXVC) to debug a remote device.
Signed-off-by: Nicolas Derumigny <nicolas.derumigny@inria.fr>
Change-Id: I934591b489e30b400b87772b1437e6030440904c
Reviewed-on: https://review.openocd.org/c/openocd/+/8595
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Adapters: bcm2835gpio, imx_gpio, am335xgpio, ep93xx and at91rm9200
Allow the user to enable them regardless of the target architecture.
Change-Id: I9fbc7cbefe770ea2e2239b95a3305fd29127fa85
Signed-off-by: R. Diez <rdiez-2006@rd10.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8892
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Macro AM_PROG_CC_C_O has been obsolete since Automake 1.14,
released in June 2013 (12 years ago).
It used to check whether the C compiler supports the -c and -o options,
but that is now included in AC_PROG_CC.
Increase the minimum required Automake version to 1.14 accordingly.
Also remove the "not a GNU package" comment,
which does not really make sense.
Change-Id: I987ba8686721c7f36fba81e100f1c3ddf77f636d
Signed-off-by: R. Diez <rdiez-2006@rd10.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8942
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
The adapter is not available for years now. There is also no information
about this device from Gateworks. The poor hardware availability and the
lack of users prevents testing, maintenance and adaptations to future
changes.
Mark the adapter as deprecated as a first step to give potential users
the opportunity to upgrade the hardware until the next OpenOCD release.
Change-Id: I037325a6b018b26608733a36bef30db2785858f8
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8651
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The adapter is not available for years now and Amontec is not even a
company anymore. The poor hardware availability and the lack of users
prevents testing, maintenance and adaptations to future changes.
Mark the adapter as deprecated as a first step to give potential users
the opportunity to upgrade the hardware until the next OpenOCD release.
Change-Id: Idd9fb75588246bc39e12ea17a71435ed77f0f50b
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8349
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
With commit d8a2f6dbcf ("configure.ac: show the Amontec
JTAG-Accelerator driver in the config summary") the driver
amt_jtagaccel is now build by default on Linux.
This highlights the dependency of some include files, dependency
that is not properly managed and that can cause build failure.
The driver is queued to be dropped soon, so there is no real
interest to fix the dependencies.
Change the default so the driver is not built if the user does not
require it at configure time.
Change-Id: Ifb74e2c802abda290efbf59ca4ce02048c94e6f8
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8939
Reviewed-by: R. Diez <rdiez-2006@rd10.de>
Tested-by: jenkins
By merging [1] and [2], the drivers 'xlnx-pcie-xvc' and 'linuxspidev'
are now build by default on Linux.
This highlights the dependency of some include files under subfolder
'linux' that are not installed by default in all Linux boxes.
Add the check in 'configure' for the presence of the include file
and conditionally enable the build of the driver.
Change-Id: Ie88645c3455ab07622f069a0cc7bf09d1a5a2c75
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Link: [1] 7214c8be46 ("configure: show adapter Xilinx XVC/PCIe in the configuration summary")
Link: [2] 83e0293f7b ("Add Linux SPI device SWD adapter support")
Reviewed-on: https://review.openocd.org/c/openocd/+/8935
Tested-by: jenkins
Introduce basic testing of error-handling in target configuration
related commands.
The tests can be run via `make check` when JTAG `dummy` adapter is
enabled.
Change-Id: Id0f382046dd70007d8e696d82d2396a7ccab7a33
Signed-off-by: Evgeniy Naydanov <evgeniy.naydanov@syntacore.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8644
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
jimtcl was integrated as Git submodule for convenience and probably also
because packages were not widely available at the time. Today, jimtcl is
available in many popular package repositories [1] and the integration
as Git submodule adds unnecessary complexity to the OpenOCD build
process. For details, see the discussion on the mailing list in [2].
Disable the jimtcl Git submodule by default and announce it as
deprecated feature that will be removed in the next release. This gives
package maintainers time to adapt to the change and, if necessary,
build a package for jimtcl.
[1] https://repology.org/project/jimtcl/versions
[2] https://sourceforge.net/p/openocd/mailman/message/58786630/
Change-Id: I07930ac07f7d7a6317c08b21dc118f4f128b331c
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8380
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The feature for 'malloc-logging' uses functionalities that are
available only in GNU libc.
Detect in 'configure' if OpenOCD is being compiled with glibc.
Set the macro '_DEBUG_FREE_SPACE_' only in case of glibc.
Change-Id: I43e9b87c7ad47171cfe3e7c1e5f96f11e19f98d0
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8592
Tested-by: jenkins
The check if 'elf.h' defines the type 'Elf64_Ehdr' is currently
done through 'grep' on the file. While there is no false positive,
so far, such test could incorrectly find the text inside a comment
or in a block guarded by #if/#endif.
Use the autoconf macro AC_CHECK_TYPE() to detect if the type is
properly declared.
Change-Id: Ibb74db3d90ac6d1589b9dc1e5a7ae59e47945e78
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8591
Tested-by: jenkins
To alleviate the need to bitbang SWD, I've written a SWD SPI
implementation. This code is inspired by the work of luppy@appkaki.com
as shown at github.com/lupyuen/openocd-spi but with the desire to be
more generic. This implementation makes use of the more common 4 wire
SPI port using full duplex transfers to be able to capture the SWD ACK
bits when a SWD TX operation is in progress.
TEST:
Connects successfully with the following combinations:
Hosts:
Raspberry Pi 4B
Unnamed Qualcomm SoC with QUPv3 based SPI port
Targets:
Raspberry Pi 2040
Nordic nRF52840
NXP RT500
Change-Id: Ic2f38a1806085d527e6f999a3d15aea6f32d1019
Signed-off-by: Richard Pasek <rpasek@google.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8645
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: zapb <dev@zapb.de>
Tested-by: jenkins
The Dummy adapter is useful when developing generic JimTcl code.
Besides, the distributed BUGS file states that you should
try to reproduce any crashes with the Dummy adapter, so
it does not make sense that it is not enabled by default.
Change-Id: I145de06de4d2c0011619b1b941200b63e200db23
Signed-off-by: R. Diez <rdiezmail-openocd@yahoo.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8608
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
List AC_ARG_ADAPTERS was missing a comma separating two of the elements.
Also verify that each adapter is set to either 'auto', 'yes' or 'no',
which should prevent such issues from going unnoticed in the future.
Change-Id: I0d407e03b1e5a3edc61d7dc93d5ffa70fe079b3c
Signed-off-by: R. Diez <rdiezmail-openocd@yahoo.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8534
Tested-by: jenkins
Reviewed-by: R. Diez <rdiez-2006@rd10.de>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Add support for code coverage collection. This helps
developers to check if their test scenarios really exercised
all the OpenOCD functionality that they intended to test.
- Option --enable-gcov has been added to configure.ac
which enables the coverage collection using Gcov. (Disabled
by default.)
- The steps to collect and inspect the coverage have been
described in HACKING file.
Change-Id: I259e401937a255e7ad7f155359a0b7787e4d0752
Signed-off-by: Jan Matyas <jan.matyas@codasip.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8521
Tested-by: jenkins
Reviewed-by: Evgeniy Naydanov <evgeniy.naydanov@syntacore.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Adapter Xilinx XVC/PCIe was not appearing in the configuration summary
because of the wrong variable name: build_xlnx_pcie_xvc
instead of enable_xlnx_pcie_xvc.
Also build this adapter automatically on Linux.
Change-Id: I69ea92f550052b9ce55ce32597ac446a15a87388
Signed-off-by: R. Diez <rdiezmail-openocd@yahoo.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8312
Tested-by: jenkins
Reviewed-by: R. Diez <rdiez-2006@rd10.de>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Cross compiling OpenOCD for Windows forces the maximum number of
open files (including sockets) to 64. See in include file
psdk_inc/_fd_types.h:
#ifndef FD_SETSIZE
#define FD_SETSIZE 64
#endif
This limit is far lower than the default value 1024 used by Linux.
In pull request #644 [1] in risc-v fork it's reported that:
- each socket server of OpenOCD (GDB, telnet, ...) uses one FD;
- each active connection to a socket server uses another FD;
- multi-core devices with 32 or more cores, each having a GDB
connection, already saturates the 64 available FD at the 26th
GDB connection.
The patch [2] proposed and merged in risc-v fork adds the compile
flag
-DFD_SETSIZE=128
to all the host types. While this looks fine for Windows, it
reduces the default value for Linux and other OS.
Add the compile flag FD_SETSIZE only to cross compile for Windows.
Link: [1] https://github.com/riscv-collab/riscv-openocd/pull/644
Link: [2] https://github.com/riscv-collab/riscv-openocd/pull/644/commits/1bab4cfbc4f4
Change-Id: Ie43a792ac11a5e63e0407b68e3f270efea0c87be
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8503
Tested-by: jenkins
