Today openocd registers the commands to jim with three methods:
1) "native" commands (.jim_handler) at root level are registered
directly as jim commands;
2) "simple" commands (.handler) at root level are registered
through the handler script_command();
3) all other commands not at root level are registered through the
handler command_unknown().
Apart from using different handler, other inconsistencies are
present:
a) command in 1) are not checked for their "mode", so are run with
no check about current mode (COMMAND_CONFIG or COMMAND_EXEC);
b) target_call_timer_callbacks_now() is called only for "simple"
commands and not for "native" commands;
c) target override is performed only for "simple" commands and not
for "native" commands.
Drop script_command() and extend command_unknown() to uniformly
handle all the cases above, fixing all the inconsistencies already
mentioned.
The handler's name command_unknown() is probably not anymore
appropriate, but will be renamed in a separate change.
Note: today all the commands in a) have mode CONFIG_ANY, apart for
"mem2array" and "array2mem" that have mode COMMAND_EXEC. But the
latter commands are registered during target init, so do not exist
during COMMAND_CONFIG and no issue is present.
Change-Id: I67bd6e47eb2c575107251b9192c676c27d4aabae
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5665
Tested-by: jenkins
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
While registering a new command, jim accepts a pointer to command's
private data that will be accessible during the command execution.
Today openocd is not consistent and passes different private data
depending on the command, and then even overwrites it:
- "simple" commands (.handler) are registered with their own
struct command pointer as command private data;
- "native" commands (.jim_handler) at root level are registered
with NULL command private data;
- "native" commands (.jim_handler) not at root level are
registered with the struct command pointer of their root command
as command private data but, when executed, the command private
data is overwritten by the value in field jim_handler_data taken
from their struct command.
Uniform the usage of command private data by always set it to the
struct command pointer while registering the new commands.
Note: for multi-word commands only the root command is registered,
so command private data will be set to the struct command of the
root command. This will change later in this series when the full-
name of the command will be registered.
Don't overwrite the command private data, but let the commands that
needs jim_handler_data to get it directly through struct command.
For sake of uniformity, let function command_set_handler_data() to
set the field jim_handler_data also for "group" commands, even if
such value will not be used.
Now Jim_CmdPrivData() always returns a struct command pointer, so
wrap it in the inline function jim_to_command() to gain compile
time check on the returned type.
While there, uniform the code to use the macro Jim_CmdPrivData()
to access the command's private data pointer.
Change-Id: Idba16242ba1f6769341b4030a49cdf35a5278695
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5664
Tested-by: jenkins
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
The target mem_ap is a convenient way to access buses, memory and
peripherals behind an ARM AP.
The current implementation provides only access through OpenOCD
commands, because GDB remote protocol has to interact with a CPU
and has to operate on CPU states and registers.
Using GDB to access the memory is welcome, because GDB can resolve
the symbol's address from an ELF file and can nicely display the
content of complex struct and data types.
Extend mem_ap target with the bare minimal support for a remote
GDB connection, by emulating a fake basic ARM core. It means that
only a GDB that has support for ARM can be used (either 'aarch64',
'arm' or 'multiarch' GDB). This is not seen as a big limitation,
because the mem_ap target is mainly used on ARM based devices.
Add a minimalist register description for the fake CPU.
Fill the field 'debug_reason' as expected by GDB server.
Call the target halted event to reply to GDB halt requests.
For backward compatibility, don't open the GDB port by default. If
needed, it has to be specified at 'target create' or 'configure'
with the flag '-gdb-port'.
Change-Id: I5a1b7adb749746516f5d4ffc6193c47b70132364
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/6034
Tested-by: jenkins
There are some breakpoint/watchpoint related code in armv8_dpm.c,
but seems not working for aarch64. Target aarch64 has its own
breakpoint implementation in aarch64.c. This commit follows the
same logic to add watchpoint support for target aarch64.
This commit also increases the size of stop_reason[] in function
gdb_signal_reply() since the old size is too small to fit in a
64-bit address, such as ffff8000115e6980.
Change-Id: I907dc0e648130e36b434220f570c37d0e8eb5ce1
Signed-off-by: Liming Sun <lsun@mellanox.com>
Signed-off-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Reviewed-on: http://openocd.zylin.com/4761
Tested-by: jenkins
Reviewed-by: Liming Sun <limings@nvidia.com>
Reviewed-by: Kevin Burke <kevinb@os.amperecomputing.com>
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Each one of CMSIS-DAP command handlers was responsible for setting
HID report number, which in case of USB bulk transport was not used
at all. The command had to be filled with 1 byte offset whereas
the response was read without an offset.
Introduce 'command' and 'response' pointers into struct cmsis_dap.
Use them for filling the command and read the response respectively.
CMSIS-DAP command parameter are now at positions as documented in
https://arm-software.github.io/CMSIS_5/DAP/html/group__DAP__Commands__gr.html
Adjust buffer allocation for HID and USB bulk transports.
While on it, use h_u32_to_le() and h_u16_to_le() instead of per-byte
writes.
Change-Id: Ib0808d6826ba0e254c1007ace8b743405536332a
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/6120
Reviewed-by: Adrian M Negreanu <adrian.negreanu@nxp.com>
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
The hidapi cmsis-dap backend is using a packet_size of
64+1: 64 is the bMaxPacketSize0 and 1 is the hid Report-Id.
In hidapi::hid_write(), the packet_size is decremented by 1 and
stored for the next transfer.
The packet_size is now valid bMaxPacketSize0=64,
so when hid_read() is called, libusb_bulk_transfer() finishes w/o timeout.
For the libusb bulk backend, the same packet_size of 64+1 is used,
but there's no hid_write() to decrement and store it for the next read.
So the next time a read is done, it will try to read 64+1 bytes.
Fix this by putting the packet logic within each backend.
Use calloc() to allocate the struct cmsis_dap to be on safer side.
Change-Id: I0c450adbc7674d5fcd8208dd23062d5cdd209efd
Signed-off-by: Adrian Negreanu <adrian.negreanu@nxp.com>
Reviewed-on: http://openocd.zylin.com/5920
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Now that the old drivers have been converted to libusb1, there is
no need to keep the build dependency from libusb0.
Drop libusb0 from configure and makefiles, remove the libusb0
helper and remove libusb0 and libusb-compat from the README files.
Change-Id: Icc05be74ae5971ba6cbb67d39107c709a4d826e6
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5993
Tested-by: jenkins
Convert the driver from libusb0 to libusb1.
Change-Id: Idef0b6cf10fab583bc8d13b3b4fadd5cc368c090
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5990
Tested-by: jenkins
Convert the driver from libusb0 to libusb1.
Change-Id: I3f334f2d02515d612097955e714910a587169990
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5992
Tested-by: jenkins
The API Jim_CreateCommand() in latest version of jimtcl leaks the
memory allocated internally by jimtcl when it converts the string
command-name to a Jim_Obj.
The fix is already merged upstream and would be available in next
jimtcl 0.81, expected in ~6 months, hopefully before the next tag
for OpenOCD v0.12.0.
OpenOCD v0.11.0 is distributed with jimtcl 0.79.
Debian distributes jimtcl as a separate library package and today
it's still on 0.79.
It make sense to keep using jimtcl 0.80 in current development
cycle to test it further. But having this background memory leak
noise hides the eventual new memory leaks that could come from the
development activity.
This patch uses the internal jimtcl API Jim_CreateCommandObj() and
correctly free the internal object, avoiding the memory leak.
Being an internal API, it is not accessible if OpenOCD is linked
with an external jimtcl library. Nevertheless, building jimtcl as
a submodule of OpenOCD makes the trick effective.
The scope of this patch is thus limited at developers that build
OpenOCD with jimtcl submodule and need to control and debug memory
leaks.
This patch is supposed to be removed as soon as jimtcl 0.81 gets
available.
The added code is located, on purpose, in an area of the file that
hopefully will not conflict other patches pending in gerrit.
Change-Id: I4d300ad21bdb6c616c3f0f14b429b4fdf360900d
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reported-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/6130
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
Reviewed-by: Jonathan McDowell <noodles-openocd@earth.li>
After bootstrapping build, if we want to do an out-of-tree build (ie: in the
OOT-build dir) we have a build failure because build system relies on
the OOT-build/src directory exists
```sh
./bootstrap
mkdir OOT-build
cd OOT-build
../configure --disable-dependency-tracking --<flag1> --<flag2> ...
make
$ LANG=C make
cat ../src/helper/startup.tcl ../src/jtag/startup.tcl ../src/target/startup.tcl ../src/server/startup.tcl ../src/flash/startup.tcl | ../src/helper/bin2char.sh > src/startup_tcl.inc || { rm -f src/startup_tcl.inc; false; }
/bin/bash: line 1: src/startup_tcl.inc: No such file or directory
make: *** [Makefile:6603: src/startup_tcl.inc] Error 1
```
These kind of errors are fixed indicating relevant directory creation in
Makefile.am before actually relying on it.
Change-Id: I8185fd41ef942184597dc4c0092796034572cbe1
Signed-off-by: Raúl Sánchez Siles <rasasi78@gmail.com>
Reviewed-on: http://openocd.zylin.com/6106
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
introduction of 'enum stm32l4_rdp' enumerating possible RDP levels for
devices with and without TrustZone.
also in 'stm32l4_flash_bank' structure we added and rdp and tzen members
to store read values by the helper 'stm32l4_sync_rdp_tzen'
these new members are used to display security and protection status
while probing the flash.
Change-Id: Icf883189715278a3323fe210d295047678b16592
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/5541
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
instead of adding a new member into stm32l4_part_info for every relevant
feature, .flags serves as container for the devices' features.
identified features: F_HAS_DUAL_BANK, F_USE_ALL_WRPXX, F_HAS_TZ
Change-Id: I3093e54c6509dec33043ebe6f87675198bf1967a
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/5540
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
stm32l4_protect: was using one WRP area per bank, without checking
if it is already protecting some sectors.
protection algo is more complicated than that, before using a WRP area
we should check if it is already used, then either reuse it for extension
(or reduction) or use a free area.
introduce a new command: stm32l4x wrp_info bank_num ['bank1'|'bank2']
this command lists the protected areas using WRP.
Note: for some devices like STM32L4R/S in single bank mode, all 4 WRP areas
are usable for that bank, to manage this case an attribute 'use_all_wrpxx'
was introduced into stm32l4_part_info and used later in protection handlers
example usage:
$ telnet localhost 4444
> flash probe 0
device idcode = 0x10036470 (STM32L4R/L4Sxx - Rev: Y)
flash size = 2048kbytes
flash mode : dual-bank
flash 'stm32l4x' found at 0x08000000
> stm32l4x wrp_info 0
no protected areas
> flash protect 0 0 4 on
set protection for sectors 0 through 4 on flash bank 0
> flash protect 0 8 9 on
set protection for sectors 8 through 9 on flash bank 0
> stm32l4x wrp_info 0
protected areas: [0,4][8,9]
> flash protect 0 6 6 on
the device WRPxy are not enough to set the requested protection
failed setting protection for blocks 6 to 6
> flash protect 0 3 5 on
set protection for sectors 3 through 5 on flash bank 0
> stm32l4x wrp_info 0
protected areas: [0,5][8,9]
> flash protect 0 6 7 on
set protection for sectors 6 through 7 on flash bank 0
> stm32l4x wrp_info 0
protected areas: [0,9]
> flash protect 0 5 6 off
cleared protection for sectors 5 through 6 on flash bank 0
> stm32l4x wrp_info 0
protected areas: [0,4][7,9]
Change-Id: I42bd84fa66edd93406e18c6d89310faa5267ffa7
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/6107
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
this is a rework of #5320 started by Andreas then abandoned.
same syntax as in stm32f2x driver:
enable OTP for writing
> stm32l4x otp 1 enable
write to OTP
> flash write_bank 1 foo.bin 0
> flash filld 0x1FFF7000 0xDeadBeafBaadF00d 1
read OTP
> mdw 0x1FFF7000 4
disable OTP
> stm32l4x otp 1 disable
Change-Id: Id7d7c163b35d7a3f406dc200d7e2fc293b0675c2
Signed-off-by: Andreas Bolsch <hyphen0break@gmail.com>
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/5537
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
In flash/nor/cfi.c:835 struct cfi_info is allocated by malloc(). As
write-mem was uninitialized the pointer pointed to an out of range
address, which led to a segmentation fault and crashed openocd.
This happened during flash-command of an external flash-bank, using
cfi.
Use calloc() instead.
While on it check for NULL return and remove unnecessary initialzation.
Change-Id: I0e2ffb90559afe7f090837023428dcc06b2e29f6
Signed-off-by: Mischa Studer <mischa.studer@csa.ch>
Reviewed-on: http://openocd.zylin.com/6070
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
In case of some error, the USB device and firmware file are still
claimed. Make sure refcounting is properly accounted for both cases.
Change-Id: I933114f68e59280e58372c0941a0062fe96ab340
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-on: http://openocd.zylin.com/6115
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
For Zephyr rtos support it is necessary to define general register
numbers for architecture. There were some already in arc.h file.
Let's define ARC registers numbers as a set instead of separate defines.
Change-Id: I63742b8608f9556c2ec9bd2661a0fd9cf88e9b74
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Reviewed-on: http://openocd.zylin.com/6105
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
This removes some warnings which prevent a successful build with -Werror
which is enabled by default. I'm using gcc 11, so maybe others are not
getting this warnings yet.
In src/flash/nor/numicro.c the debug messages were misleadingly indented.
In src/target/arm920t.c the array size where smaller than expected from
the receiving function.
Change-Id: I66f5c6a63beb9f9416e73b726299297476c884d8
Signed-off-by: Rene Kita <git@rkta.de>
Reviewed-on: http://openocd.zylin.com/6104
Reviewed-by: Jonathan McDowell <noodles-openocd@earth.li>
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
