No driver directly working with the USB hardware needs additional
time to complete the write op, they always return transfer complete
status immediately after submitting the transfer.
Although there is implemented correct waiting path in cmsis_dap_usb_write()
it was marked by error logs to catch any suspicious behaviour during
debugging of asynchronous libusb transfers.
However there are drivers which need waiting to finish write op:
at least usbipd-win, IP tunnelled USB driver, was reported
to flood the log with the related errors.
Change LOG_ERROR to LOG_DEBUG_IO in the code waiting to finish write op.
Reported-by: Quentis Ghyll <quentisgh@gmail.com>
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: Iedf2c96d851f22e694efaf13a2d6a2a408cee1ad
Reviewed-on: https://review.openocd.org/c/openocd/+/8640
Tested-by: jenkins
CMSIS-DAP bulk backend read op used two timeouts: transfer timeout
used in libusb_fill_bulk_transfer() and wait timeout used optionally
in libusb_handle_events_timeout_completed().
The real usage is limited to two cases only:
1) blocking read: the same timeout is used for both transfer
and wait
2) non-blocking read: transfer timeout is used in
libusb_fill_bulk_transfer(),
libusb_handle_events_timeout_completed() is called with zero timeout.
Use blocking flag as read op parameter to distinguish between
these two cases.
See also [1]
Link: [1] 8596: jtag: cmsis_dap: include helper/time_support.h | https://review.openocd.org/c/openocd/+/8596
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: Ia755f17dc72bb9ce8e02065fee6a064f8eec6661
Reviewed-on: https://review.openocd.org/c/openocd/+/8639
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Use LOG_TARGET_xxx() for log messages as it is used for other targets.
While at it, rework the log messages, for example by removing spaces
or punctuation marks at the end of the message.
Change-Id: I3dd4314d354b5628144f98325540926981778616
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8665
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Add a target-related log function for user messages as it already
exists for other log levels.
Change-Id: I9076677d6451b900332583e748bab3f83df56d3b
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8661
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Previously, Linux assigned gpiochip numbers sequentially depending on
when the chip driver was probed. As RP1 is on the end of a PCIe link, it
is probed later than the on-board chips (including expanders connected
over SPI/I2C). This meant that RP1's gpiochip assignment was at an
offset that could potentially change.
A downstream kernel patch now assigns fixed offsets for RP1 and the
onboard gpiochips. Query the device tree to get proper GPIO_CHIP index.
Change-Id: I759978d4b3021c815a7d9febb41961cd1d3d185c
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/8650
Reviewed-by: Jonathan Bell <jonathan@raspberrypi.com>
Tested-by: jenkins
The RISC-V coprocessor is currently not supported. It is attached to the
DAP via AP#2 but the AP implementation is unknown.
The nRFL54L series uses resistive RAM (RRAM) as non-volatile memory
which can be programmed directly. Since it does not fit in the current
flash memory infrastructure of OpenOCD there is no NVM support so far.
Change-Id: I9934af4fd3bb8b7272954fc4b17638c7dabbbee0
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8609
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
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>
The command 'arm core_state' uses the enum in 'arm->core_state' as
an index in the table of strings to print the core state.
With [1] the enum has been extended with the new state for AArch64
but not the corresponding table of strings.
This causes an access after the limit of arm_state_strings[].
Rewrite the table using c99 array designators to better show the
link between the enum list and the table.
Add the function arm_core_state_string() to check for out-of-bound
values allover the file.
Change-Id: I06473c2c8088b38ee07118bcc9e49bc8eafbc6e2
Fixes: [1] 9cbfc9feb3 ("arm_dpm: Add new state ARM_STATE_AARCH64")
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8594
Tested-by: jenkins
The log messages are very inconsistent across the code base. Add a
guideline for log messages to help improve consistency. The guideline is
based on the most commonly used style in the current code base.
Change-Id: I076d68abe588dd04b59580379e97b82d537def23
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8576
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
