The value returned by target_get_gdb_arch() is something specific for GDB.
There could be several variants of the same CPU.
If we start implementing all the variants, checking the string value,
could become incorrect.
It's better to check for xtensa->common_magic == XTENSA_COMMON_MAGIC
Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: I20f3fdced176c3b9ab00f889743161ecad7280f9
Reviewed-on: https://review.openocd.org/c/openocd/+/7536
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Almost written from the beginning in a modern OpenOCD way.
- Endiannes support
- Proper variable types
- Align with the other rtos implementations
Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: I0868a22da2ed2ab664c82b17c171dc59ede78d10
Reviewed-on: https://review.openocd.org/c/openocd/+/7444
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
-noreset: when using several SVF input files in a sequence it is not always
desireable to have a JTAG reset between the execution of the files.
The -noreset option skips this unwanted reset.
-addcycles <x>: some tests rely on a certain number of extra clock cycles
between the actual JTAG commands. The -addcycles option injects a number
x cycles after each SDR instruction.
Signed-off-by: Kai Schmitz <kai.schmitz@advantest.com>
Change-Id: I31932d6041dbc803be00016cd0a4f23fb2e7dbe1
Reviewed-on: https://review.openocd.org/c/openocd/+/7433
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
With the new checkpatch we will not get this type of issues
anymore.
In mean time, let's fix what we have missed during the review
process.
Change-Id: Iecebf9d43f51a29ee09505d360792793afd24b40
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Fixes: 53556fcded ("tcl/interface: add Ashling Opella-LD FTDI config files")
Reviewed-on: https://review.openocd.org/c/openocd/+/7530
Tested-by: jenkins
The new version modifies it's auto configure in change
https://github.com/msteveb/jimtcl/commit/ccd47be13019
stating:
configure: Default to --full
Now use --minimal and/or --without-ext to disable things.
With such change jimtcl doesn't build anymore as OpenOCD submodule
because of errors linking with new dependencies openssl and zlib.
Use option --minimal to keep the same build configuration as with
former jimtcl 0.81.
Add option --disable-ssl to avoid a build error on system with no
ssl libraries installed. This is already fixed in jimtcl upstream
but not part of 0.82. Note that ssl is not currently used by
OpenOCD.
Change-Id: I0879891dbd083bfbff1e904daf6cd549c3329bbf
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7517
Tested-by: jenkins
The issues have been highlighted while integrated jimtcl 0.82,
but were already present.
While building jimtcl as submodule, OpenOCD generates the file
jimtcl/configure.gnu to pass specific configure flags.
Issue 1: this file is not included in the distribution.
This causes the rebuild from the distribution to have a jimtcl
built with different (the default) configure flags.
With jimtcl 0.82 the new default is to enable all the features,
but a bug causes the build to fail when openssl is not installed
in the build system (the bug is already fixed but after 0.82 [1]).
All these together cause OpenOCD Jenkins to fail the build for
target 'distcheck' with jimtcl 0.82.
Add jimtcl/configure.gnu to OpenOCD distribution's file list.
The build system considers jimtcl/configure.gnu as a temporarily
file that should be removed during 'distclean'.
Issue 2: 'distcheck' set read-only permission to the source files,
including jimtcl/configure.gnu, so 'distclean' fails removing it.
Add a leading '-' to ignore errors while trying to remove the
file.
Issue 3: Now that 'distcheck' properly configures and builds
jimtcl, 'distcheck' still fails because we have enabled jimtcl
json support in [2] and jimtcl 'distclean' fails to properly
remove one object file (fixed after 0.82 [3]).
Make OpenOCD removing the file jimtcl/jsmn/jsmn.o to complete
the execution of 'distcheck'. Add a comment specifying which of
the jimtcl versions are affected.
Change-Id: I2f9153c5a41ba66b989b27c7bc57b38d1744cc29
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Link: [1] https://github.com/msteveb/jimtcl/commit/22277943a19c
Link: [2] 0a36acbf6a ("configure: build jimtcl with json extension")
Link: [3] https://github.com/msteveb/jimtcl/commit/32a488587a3e
Reviewed-on: https://review.openocd.org/c/openocd/+/7527
Tested-by: jenkins
Reviewed-by: zapb <dev@zapb.de>
Not all compilers nor compiler versions supports the attributes
used in OpenOCD code.
Collect in a single file the workaround to handle them.
Change-Id: I92d871337281169134ce8e40b2064591518be71f
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7519
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
We were previously not zero-initializing ELF segments between p_filesz
and p_memsz (aka BSS). However, this may be necessary depending on the
user's application. Therefore, start doing so.
Change-Id: I5a743390069583aca7ee276f53afeccf2cac0855
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7513
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The driver tries to open mpsse engine for each vid pid
pair in sequence. If more vid/pid pairs are configured and
the USB device does not correspond to the first pair,
the driver shows 'unable to open ftdi device ...' error.
Match vid pid with the whole list as used in jtag_libusb_open()
instead of multiple mpsse_open() in for loop over vid/pid pairs.
Change-Id: I8ef55205be221c727607fe25b81ae21de0d96f02
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/7529
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Wolfram Sang <wsa@kernel.org>
SAM9260 gained good generic infrastructure since 2009. And we always
want "improvements", no need for a TODO item.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Change-Id: I92551ef9d42ee47ad7441f2354587bbb45edc97e
Reviewed-on: https://review.openocd.org/c/openocd/+/7526
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
We currently fail the transfer when issuing more than 255 transactions
at once, e.g.
> read_memory 0x10000000 32 256
CMSIS-DAP transfer count mismatch: expected 257, got 1
This is because the protocol only supports 255 transactions per packet
(65535 for block transactions), and as a result we truncate the
transaction count when assembling the packet. Fix it by running the
queue when we hit the limit.
Change-Id: Ia9e01e3af5ad035f2cf2a32292c9d66e57eafae9
Signed-off-by: Peter Collingbourne <pcc@google.com>
Fixes: 40bac8e8c4 ("jtag/drivers/cmsis_dap: improve USB packets filling")
Reviewed-on: https://review.openocd.org/c/openocd/+/7483
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
The OpenOCD commands produce their TCL text result through the
pair command_print() and command_print_sameline().
The latter is used to concatenate output in a single line.
At the end of a sequence of command_print(), the last LF is taken
as part of the command result, while it is not always needed, and
it is even annoying when the output of two commands needs to be
concatenate in a single line.
Using command_print_sameline() in place of the last call to
command_print() would solve the problem but it's quite expensive
in term of coding to fix all the existing commands.
Drop the last LF, if present.
Commands that would specifically need a LF as last char, can add
an extra LF at the end of the output.
Document this behavior in command.h.
Change-Id: I6757c20fbfce923dd393083146e8d5a1f3b790b4
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7471
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
A bunch of new SPI flash (Adesto, Cypress, XTX Tech, mainly octal)
IDs and SPI FRAM (Infineon) IDs added. Backward compatible change
of ID interpretation: The previously unused 4th byte now acts
as continuation code (0x7F) count for manufacturer id, cf.
JEDEC JEP106BC. Currently this affects only some recent octal flash
and FRAM devices, which are only supported by stmqspi and cmspi
flash drivers.
Change-Id: Ibdcac81a84c636dc68439add4461b959df429bca
Signed-off-by: Andreas Bolsch <hyphen0break@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6929
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
