The STM32L5 and U5 devices have DBGMCU_CR trace related bits changed
wrt other STM32 devices.
Fix the setting in configuration script.
Change-Id: I0bbc48e7b1290b603c6966cf5ddd42df389e6ede
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/7117
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
- Config files for DAP/JTAG and DAP/SWD systems
- Xtensa core config definitions for NXP RT685 with Xtensa HiFi DSP
Signed-off-by: Ian Thompson <ianst@cadence.com>
Change-Id: I9c3280052073d86e09c7553de661eb8662a95c4a
Reviewed-on: https://review.openocd.org/c/openocd/+/7145
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
While reviewing on gerrit the change
https://review.openocd.org/6932/
it get clear that the missing documentation on stm32f4x's code
was triggering errors in the new change.
OpenOCD is currently unable to read traces, but these can be
hopefully be read with some other tool.
Document the settings for enabling trace on stm32[fl]4x.
Change-Id: Ibae77a53de16375d3d500e728678740095547009
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6945
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
With commit dc7b32ea4a ("armv7m_trace: get rid of the old tpiu
code") the target's event "trace-config" has been deprecated.
Create the TPIU device.
Replace the target's event "trace-config" with tpiu's event
"pre-enable" in the STM32 devices that require enabling the trace
clock _before_ programming the TPIU.
Make the script multi-instance-able in case it's used for JTAG
chained devices.
Uniform the code in STM32F4x with the other scripts.
Remove the empty event from STM32WLx.
Change-Id: Ifda219c3c5f37e03072a88168611cf505eb630b7
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6681
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Generic Xtensa LX support extends the original Espressif/Xtensa
patch-set to support arbitrary Xtensa configurations, as defined in
a core-specific .cfg file. Not yet fully-featured. Additional
functionality to be added:
- Xtensa NX support
- DAP/SWD support
- File-IO support
- Generic Xtensa multi-core support
Valgrind-clean, no new Clang analyzer warnings
Signed-off-by: Ian Thompson <ianst@cadence.com>
Change-Id: I08e7bf8fa57c25b5d0cb75a1aa7a2ac13a380c52
Reviewed-on: https://review.openocd.org/c/openocd/+/7055
Tested-by: jenkins
Reviewed-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
This patch adds support for DAP interface to Cadence vdebug driver.
It implements a new transport layer for dapdirect_swd.
Change-Id: I64b02a9e1ce91e552e07fca692879655496f88b6
Signed-off-by: Jacek Wuwer <jacekmw8@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6965
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
For historical reasons, no license information was added to the
tcl files. This makes trivial adding the SPDX tag through script:
fgrep -rL SPDX tcl/ target| while read a;do \
sed -i '1{i# SPDX-License-Identifier: GPL-2.0-or-later\n
}' $a;done
With no specific license information from the author, let's extend
the OpenOCD project license GPL-2.0-or-later to the files.
Change-Id: I7b2610300b24cccd07bfa6fb5f1266970d5d3a1b
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7027
Tested-by: jenkins
The SPDX tag is aimed at machine handling and it's thus expected
to be placed in the first line.
Change-Id: I3992856eeb28b333c38d010ef286e22471ede263
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7026
Tested-by: jenkins
OpenOCD project is switching to SPDX tags.
Replace the few FSF boilerplate in tcl folder.
Change-Id: I15b146eb77cc491ed7355178f684f3e76fc763b4
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7025
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
In order to facilitate debugging multiple cores, specify the coreid and
the hwthread rtos in the imx8m target configuration.
Change-Id: Ibd871517a160ceca15002fb10e27cb793f14d086
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-on: https://review.openocd.org/c/openocd/+/7019
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
ESP32-S3 is a dual core Xtensa SoC
Not full featured yet. Some of the missing functionality:
-Semihosting
-Flash breakpoints
-Flash loader
-Apptrace
-FreeRTOS
Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: I44e17088030c96a9be9809f6579a4f16dbfc5794
Reviewed-on: https://review.openocd.org/c/openocd/+/6990
Tested-by: jenkins
Reviewed-by: Ian Thompson <ianst@cadence.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
ESP32 is a dual core Xtensa SoC
Not full featured yet. Some of the missing functionality:
-Semihosting
-Flash breakpoints
-Flash loader
-Apptrace
-FreeRTOS
Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: I76fb184aa38ab9f4e30290c038b5ff8850060750
Reviewed-on: https://review.openocd.org/c/openocd/+/6989
Tested-by: jenkins
Reviewed-by: Ian Thompson <ianst@cadence.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Add Ampere Altra ("Quicksilver") and Ampere Altra Max ("Mystique")
target/board configuration files.
The target configuration file supports silicon and emulation.
The board configuration files support 1 and 2 socket platforms.
Tested on Ampere emulation and silicon
Change-Id: I036c798a50624e30ab51ccd2895b6f60c40be096
Signed-off-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/5591
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
ESP32-S2 is a single core Xtensa chip.
Not full featured yet. Some of the missing functionality:
-Semihosting
-Flash breakpoints
-Flash loader
-Apptrace
-FreeRTOS
Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: I2fb32978e801af5aa21616c581691406ad7cd6bb
Reviewed-on: https://review.openocd.org/c/openocd/+/6940
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Ian Thompson <ianst@cadence.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
The LS1028A is similar to the LS1088A, except that it has 2 CPUs (and
different ethernet capabilities). From a JTAG perspective, all that's
different is the number of CPUs and the TAPID.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Change-Id: Iba3a0ecfbf82cfcfeb7eea42d52121c3b9dc93a2
Reviewed-on: https://review.openocd.org/c/openocd/+/6976
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Several Layerscape processors (LS1088A, LS2088A, LS2160A, and LS1028A)
share a common architecture. Break out the common setup from the LS1088
config in preparation for adding the LS1028A. There's no official name
for this series of processors, but NXP refers to them as "chassis
generation 3" in U-Boot, so we'll go with that too.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Change-Id: Ic6f89f95c678101f54579bcaa5d79c5b67ddf50a
Reviewed-on: https://review.openocd.org/c/openocd/+/6975
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Added support for the new Renesas RISC-V
device: RZ/Five
Signed-off-by: micbis <michele.bisogno.ct@renesas.com>
Change-Id: Id8ba29b83528c0bfe4f9b4ed21b0151a6e853bd7
Reviewed-on: https://review.openocd.org/c/openocd/+/6974
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Added support for two new devices: RZ/G2LC and RZ/G2UL
Change-Id: Iec6ba88c1d279f50808b060343b45c796bbfdbfc
Signed-off-by: micbis <michele.bisogno.ct@renesas.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6972
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Added bluenrg-lps support
Added file for the board steval-idb012v1
Fixed size_info information using a mask
Changed the if condition in bluenrg-x.cfg to be valid only for bluenrg-1 and bluenrg-2
Signed-off-by: Salvatore Giorgio PECORINO <salvatore-giorgio.pecorino@st.com>
Change-Id: Ic0777ec0811ee6fac7d5e1d065c4629e47d84a1f
Reviewed-on: https://review.openocd.org/c/openocd/+/6928
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The flash is compatible with stm32f1x, reuse the driver.
Extend the size of work area to RAM size of the smallest device.
Stop watchdogs before flash programming.
Change-Id: I67a7654a6e196f9d4b2409edaa7990c53334437e
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/6711
Tested-by: jenkins
Reviewed-by: Tim Newsome <tim@sifive.com>
Replace deprecated commands 'mem2array' and 'array2mem' with
new Tcl commands 'read_memory' and 'write_memory'.
Change-Id: I116d995995396133ca782b14cce02bd1ab917a4e
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/6859
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The LS1046A is a quad-core processor from NXP in the layerscape family.
This SoC is a bit tricky to program: while the AArch64 CPUs are
little-endian, most of the peripherals are big-endian. Care must be
taken when interpreting memory reads/writes. This processor is in the
same family as the ls1012a, so the setup is similar.
If you use OpenOCD to attach early in the boot process, only the cpu0
may be available. Trying to halt other CPUs will fail. To avoid this,
defer examination of cpus 1-3, and provide a core_up helper (like e.g.
zynqmp).
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Change-Id: If5a1a9441fb35fea3e05dc708b42e0cb3bbf2a54
Reviewed-on: https://review.openocd.org/c/openocd/+/6854
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Original TLC syntax uses 'set varname' to retrieve the value of
variable 'varname'. Such archaic syntax is still valid, but the
shorter '$varname' makes the code easier to read.
Replace 'set varname' with '$varname'.
While there, remove some useless curly brackets.
Change-Id: I27310e8c05afe56ea8bd0e41d4ae2c34447b725c
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6863
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Add support for the latest in TI k3 family AM625 SoC.
For further details, see https://www.ti.com/lit/pdf/spruiv7
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: Ia54d0eab1c30a973afb1c2c61f4c5a72d29d9b78
Reviewed-on: https://review.openocd.org/c/openocd/+/6798
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Add support for the latest in TI k3 family J721S2 SoC.
For further details, see http://www.ti.com/lit/pdf/spruj28
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I608ab4513ffb6b5c4166ba423e7d0dddbbb3bbfd
Reviewed-on: https://review.openocd.org/c/openocd/+/6796
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Since we can detect the type of target as well, reuse the _cpu_no_smp_up
function name and use the target name to simplify the _up function and
maintain consistency with what we introduced for r5.
Lets introduce gdb-attach event in a much cleaner fashion.
NOTE: we add a halt 1000 to retain the default gdb-attach hook behavior
While at it, fix a minor type of s/are/as in "Set Default target are
core 0" and simplify the foreach usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I3259b7c3ae4c71b06d921edfaefe17c03bb673dc
Reviewed-on: https://review.openocd.org/c/openocd/+/6616
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Since we can detect the type of target as well, make the attach
function name generic for the follow on cleanup patch on armv8 to use
as well.
Lets introduce gdb-attach event in a much cleaner fashion. We can
introduce a simpler r5_up function since we now have more descriptive
core names making the individual descriptive procs redundant.
NOTE: we add a halt 1000 to retain the default gdb-attach hook behavior
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I31506bb2b86e63638082640eb72aa7c4c9575e93
Reviewed-on: https://review.openocd.org/c/openocd/+/6617
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
R5 targets are currently named r5.0..n and the only way for user to
determine the actual type is external documentation. Lets just rename
the target names to make them descriptive to not require external
documentation for finding which R5 to connect to.
NOTE: we leave the _mcu_r5_cores _main0_r5_cores _main1_r5_cores alone
for now to allow existing startup proc functions to work, but we will
drop it in the follow on patch.
Previously:
Info : starting gdb server for j721e.cpu.r5.0 on 3336
Info : Listening on port 3336 for gdb connections
Info : starting gdb server for j721e.cpu.r5.1 on 3337
Info : Listening on port 3337 for gdb connections
Info : starting gdb server for j721e.cpu.r5.2 on 3338
Info : Listening on port 3338 for gdb connections
Info : starting gdb server for j721e.cpu.r5.3 on 3339
Info : Listening on port 3339 for gdb connections
Info : starting gdb server for j721e.cpu.r5.4 on 3340
Info : Listening on port 3340 for gdb connections
Info : starting gdb server for j721e.cpu.r5.5 on 3341
Info : Listening on port 3341 for gdb connections
With this patch:
Info : starting gdb server for j721e.cpu.mcu_r5.0 on 3336
Info : Listening on port 3336 for gdb connections
Info : starting gdb server for j721e.cpu.mcu_r5.1 on 3337
Info : Listening on port 3337 for gdb connections
Info : starting gdb server for j721e.cpu.main0_r5.0 on 3338
Info : Listening on port 3338 for gdb connections
Info : starting gdb server for j721e.cpu.main0_r5.1 on 3339
Info : Listening on port 3339 for gdb connections
Info : starting gdb server for j721e.cpu.main1_r5.0 on 3340
Info : Listening on port 3340 for gdb connections
Info : starting gdb server for j721e.cpu.main1_r5.1 on 3341
Info : Listening on port 3341 for gdb connections
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I2989efe3ae3e16754f98fa1dc9363ec4c898f7c3
Reviewed-on: https://review.openocd.org/c/openocd/+/6627
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The MCU is present on few of the SoCs and is meant as General Purpose
(GP) MCU of the system. Lets rename it to make clear what we are
debugging - esp when multiple MCUs are present in the system.
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I16132d321daf6e9b1d893fe6f92026d5aa9eb152
Reviewed-on: https://review.openocd.org/c/openocd/+/6619
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The M3 is the system controller of the system. Lets rename it to make
clear what we are debugging - esp when multiple MCUs are present in the
system.
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I4cd03b6068b8ce140fd254f9dd88151c4c7006d7
Reviewed-on: https://review.openocd.org/c/openocd/+/6618
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Add gdb-attach event to call the "up" function of m3 and m4 allowing for
more seamless integration with gdb for end users. We still retain _up
functions for non-gdb functionality.
NOTE: we add a halt 1000 to retain the default gdb-attach hook behavior
Suggested-by: Antonio Borneo <borneo.antonio@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I2e51fdbd8756f156551e589c748c3a338afa655c
Reviewed-on: https://review.openocd.org/c/openocd/+/6615
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
both stm32l5x and stm32u5x configs are almost identical except
clock config.
while at there rename target procs to avoid issues with JTAG daisy
chaining.
Change-Id: Ibbb1dfeb91a7f8d5d45744cf57dca2877f60e0c5
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6596
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Normally the service processor is not necessary for debugging. However,
if you are using the hard-coded RCW or your boot source is otherwise
corrupt, then the general purpose processors will never be released from
hold-off. This will cause GDB to become confused if it tries to attach,
since they will appear to be running arm32 processors. To deal with
this, we can release the CPUs manually with the BRRL register. This
register cannot be written to from the axi target, so we need to do it
from the service processor target. This involves halting the service
processor, modifying the register, and then resuming it again. We try
and determine what state the service processor was in to avoid resuming
it if it was already halted.
The reset vector for the general purpose processors is determined by the
boot logation pointer registers in the device configuration unit.
Normally these are set using pre-boot initialization commands, but if
they are not set then they default to 0. This will cause the CPU to
almost immediately hit an illegal instruction. This is fine because we
will almost certainly want to attach to the processor and load a program
anyway.
I considered adding this as an event handler for either gdb-attach or
reset-init. However, this command shouldn't be necessary most of the
time, and so I don't think we should run it automatically.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Change-Id: I1b725292d8a11274d03af5313dc83678e10e944c
Reviewed-on: https://review.openocd.org/c/openocd/+/6850
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The LS1088A is an octo-core aarch64 processor from NXP in the layerscape
family. The JTAG is undocumented, but I was able to figure things out
from the output of `dap info`. This is the first in-tree example of
using the hwthread rtos (as far as I know), so hopefully it can serve as
an example to other developers. There are some ETMs, but I was unable to
try them out because I got 'invalid command name "etm"' when trying to
test things out.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Change-Id: I9b0791d27d8c41170a413a8d86431107a85feba2
Reviewed-on: https://review.openocd.org/c/openocd/+/6848
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Changed flash driver to support writing to the user data page, as well as to any portion of the lockbits page above 512 bytes (the amount used for the actual page lock words). The top part of the lockbits page is used on at least the EFR32xG1 chips for the SiLabs bootloader encryption keys.
As presented to the user, the lockbits page is the same size as the other pages, but any attempt to write to its low 512 bytes is an error. To enforce this, efr32x_write is renamed to efm32x_priv_write and a wrapper function is provided in its place. If the user erases the lockbits page, the driver rewrites the cached lock words after the erase. When the driver erases the lockbits page in order to update the lock words, it first takes a copy of anything stored in the top part of the page, and re-programs it after the erase operation.
There are now multiple instances of flash_bank for each target, and the flash_bank instances must share their cached lock words to operate as intended. Therefore, when a bank is created, the global flash bank list is used to find any other banks that share the same target. Since some banks in the global list are invalid at the time free_driver_priv is called, reference counting is used to decide when to free driver_priv.
To avoid the need to find the lockbits flash_bank from another flash_bank, efm32x_priv_write and efm32x_erase_page now take an absolute address.
There didn't seem to be any reason to prohibit unprotecting individual flash pages, so that limitation is removed from efm32x_protect().
This addresses ticket #185.
Valgrind-clean, except for 2x 4kiB not freed/still reachable blocks that were allocated by libudev.
No new Clang analyzer warnings, no new sanitizer warnings.
Signed-off-by: Doug Brunner <doug.a.brunner@gmail.com>
Change-Id: Ifb22e6149939d893f386706e99b928691ec1d41b
Reviewed-on: https://review.openocd.org/c/openocd/+/6665
Tested-by: jenkins
Reviewed-by: Fredrik Hederstierna <fredrik.hederstierna@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
The stm32mp13x has one core Cortex-A7.
The board Discovery Kit includes an on-board STLink-V3 with SWD
connection.
The webpage of the board is not active yet.
Change-Id: I8836b26612a160ead79766955ebefaf3d21a329c
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6675
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
GD32E23x from GigaDevice is cortex-M23 microcontroller and it can work with the stm32f1x driver.
Modifications are similar to this done for GD32F1x0 in #6164 (https://review.openocd.org/c/openocd/+/6164).
Configuration file is added because its cortex-M23 CPU ID is different.
I think that GigaDevice microcontrollers should be handled in an independent unit to separate them from STM32,
but nowadays quick solution is welcome.
Signed-off-by: asier70Andrzej Sierżęga <asier70@gmail.com>
Change-Id: I91f31f5f66808bc50a8f607ac2c107e6b7c5e2b8
Reviewed-on: https://review.openocd.org/c/openocd/+/6527
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tomas Vanek
Ian Thompson
Toms Stūrmanis
Erhan Kurubas
Antonio Borneo
Jacek Wuwer
Adrien Grassein
Alvin Šipraga
Daniel Goehring
Sean Anderson
micbis
Salvatore Giorgio PECORINO
Markus Reiter
Tarek BOCHKATI
Marc Schink
Nishanth Menon
Doug Brunner
asier70