Conflicts are related to `unsigned`->`unisgned int` cleanup:
* `src/jtag/drivers/ftdi.c` -- between
6749c70a3a and
a64dc23bf1.
* `src/rtos/hwthread.c` -- between
ef3e61bebc and
436e6f1770.
* `src/target/target.c` and `.h` -- between
53ec10b61d and
e72733d590.
* `src/target/riscv/*` -- due to
957eb741a0 and
fec3b22421.
Resolved by:
* Changing the return type of `riscv_batch_get_dmi_read_op()` to
`uint32_t`.
* Using RISC-V OpenOCD's version in other cases.
Change-Id: Ia6e2129c6fddb1dec26adcd936506af2539412ef
In previous implementation, it was known that it does not perform
full reset, and that some peripherals, such as GLB core,
which handles among other stuff GPIOs, was not reset.
It was presumed, that full reset by software is not possible,
although, by accident, even when comment says that
CTRL_PWRON_RESET is set to 1, it is not
(value written into 0x40000018 supposed to be 0x7, not 0x6).
CTRL_PWRON_RESET indeed triggers full "power-on like" reset,
so this method is implemented in this commit.
There are some workarounds to make reset seamless, without any
error messages, which are described in comments of TCL script.
Only down-side of this reset is, that chip is halted after reset
bit later in BootROM than previous implementation,
but it's still good.
Change-Id: Ife2cdcc6a2d96a2e24039bfec149705baf046318
Signed-off-by: Marek Kraus <gamelaster@outlook.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8529
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Rename file to get it more generic and add more targets belonging
to the same family.
Add support for two new devices: RZ/V2L and RZ/G3S
Change-Id: Idb7f4d81d2f95ad15ef686e940f43ed29f49f343
Signed-off-by: MicBiso <michele.bisogno.ct@renesas.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8211
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
This adds support for TI CC13X2X7 / CC26X2X7 family.
For further details, see https://www.ti.com/lit/ug/swcu192/swcu192.pdf.
Change-Id: Ifd9b505716ddf0abbdd00f617e50a93a3d4fbe6a
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8193
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Vaishnav M A <vaishnav@beagleboard.org>
The _targets has to be global as it is accessed at the end of this file.
This is already the case for setup_a5x {}, assure it is the same way for
setup_crx{} . Without this change, the _targets at the end of this file
is empty in case the Cortex-R is the boot core, fix this.
Change-Id: I4979e3125ec7d93bbd56eee0096ae1d9c5f6a565
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8470
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
- src/jtag/drivers/ftdi.c:
```
++<<<<<<< HEAD
+ int i;
+ static const uint8_t zero;
++=======
+ uint8_t zero = 0;
++>>>>>>> ocd_upstream
```
Decided to choose the latter.
- src/target/riscv/riscv-013.c:
```
++<<<<<<< HEAD
+ int abs_chain_position;
+ /* The base address to access this DM on DMI */
+ uint32_t base;
++=======
+ unsigned int abs_chain_position;
+
++>>>>>>> ocd_upstream
```
Decided to choose the latter (abs_chain_position is unsigned now)
- src/target/riscv/batch.c:
```
++<<<<<<< HEAD
++=======
+ void dump_field(int idle, const struct scan_field *field)
+ {
...
+ }
++>>>>>>> ocd_upstream
```
dump_field function is not needed anymore
Signed-off-by: Parshintsev Anatoly <anatoly.parshintsev@syntacore.com>
Adds initial support for the BL702 series of chips, BL702, BL704 and BL706.
No flash bank support yet.
File name bl702.tcl was chosen over bl70x.tcl, because Bouffalo Lab
uses bl702 to mark the whole series in many of their tools.
The ndmreset bit in the RISC-V Debug Module isn't implemented correctly,
so it doesn't trigger a system reset as it should.
To solve this problem, the software reset is implemented
in the reset-assert-pre hook, which uses best reset method I could find.
What is not reset is the GLB core, which handles GPIOs, pinmux, etc.
The reset mechanism has been extensively tested, and works correctly
for both "reset run" and "reset halt", which the latter
halts very early in the BootROM.
Change-Id: I5ced6eb3902d1b9d9c1bba56f817ec5dc3493cb0
Signed-off-by: Marek Kraus <gamelaster@outlook.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8407
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Direct memory driver swd native configuration for am62a7, am62p and
J722S SoCs. All three share common memory map for the debug address
map, so there is a strong reuse. However, introduce board file
specific to the board to allow users to directly get started.
Change-Id: I5609925a2e9918fd4c91d9fd40fbee98de27fdbc
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8283
Tested-by: jenkins
Reviewed-by: Vaishnav M A <vaishnav@beagleboard.org>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
The flag '-coreid' is used by the command 'target create' to
specify the debug controller of the target, either in case of a
single debug controller for multiple CPU (e.g. RISC-V harts) or
in case of multiple CPU on a DAP access port (e.g. Cortex-A SMP
cluster).
It is also currently used to specify the CPU ID in a SMP cluster,
but this is going to be reworked.
This flag has no effects on Cortex-M; ARM specifies that only one
CPU Cortex-M can occupy the DAP access port by using hardcoded
addresses.
The flash driver 'psoc6' uses the flag '-coreid' to detect if the
current target is the Cortex-M0 on AP#1 or the Cortex-M4 on AP#2
in the SoC.
There are other ways to run such detection, without using such
unrelated '-coreid' flag, e.g. using the AP number or the arch
type of the target.
Use the arch type to detect Cortex-M0 (ARM_ARCH_V6M) vs Cortex-M4
(ARM_ARCH_V7M).
Drop the flags '-coreid' from the psoc6 configuration file.
Change-Id: I0b9601c160dd4f2421a03ce6e3e7c55c6212f714
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8128
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Conflicts:
* `doc/openocd.texi`: due to d382c95d57,
resolved by selecting the upstream version.
* `src/server/gdb_server.c`: between
944fe66f10 and
92e8823ebd. Resolved by adopting the use
of `LOG_TARGET_*`.
* `src/target/target.c`: between
639e68a621 and
c5358c84ad, selected the version from
`riscv-openocd`.
Change-Id: Ic1327f25e147945e0ec82947a82452501e8ee5de
Both devices can be configured with or without SWD multidrop.
nRF53 network core is examined on demand to avoid problems
when the core is forced off.
Change-Id: I08f88ff48ff7ac592e9214b89ca8e5e9428573a5
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/8113
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Conflict in src/rtos/FreeRTOS.c due to
fbea7d5d38 -- resolved by replacing
`target->type->name` with a call to `target_type_name()`.
Change-Id: I56702c6133894458903de7a4d764903004aa8b86
Configure the TRACECONFIG.TRACEPORTSPEED register depending on the
trace clock speed. Also catch invalid trace clock speeds.
Change-Id: I1ece1cc59da539732d2d71f296fd55799c195387
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8256
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Use 'error' instead of 'echo' for error messages. Otherwise, capturing
is always started, for example with an unsupported device.
While at it, make the error messages more consistent and clear.
Change-Id: I83c9abfb4514e6b638c4be14651e67f768af8bad
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8255
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: <post@frankplowman.com>
Add some helpers for booting ZynqMPs over JTAG. Normally, the CSU ROM
will load boot.bin from the boot medium. However, when booting from JTAG
we have to do this ourselves. There are generally two parts to this.
First, we need to load the PMU firmware. Xilinx's tools do this by
attaching to the PMU (a Microblaze CPU) over JTAG. However, the TAP is
undocumented and we don't have any microblaze support in-tree. So
instead we do it the same way FSBL does it:
- We ask the PMU to halt
- We load the firmware into the PMU RAM
- We ask the PMU to resume
The second thing we need to do is start one of the APU cores. When an
APU is released from reset, it starts executing at the value of its
RVBARADDR. While we could load the APU firmware over the AXI target,
it is faster to load it over the APU target. To do this, we put the APU
into an infinite loop before halting it. As an aside, I chose to use the
"APU" terminology as opposed to "core" to make it clear that these
commands operate on the A53 cores and not the R5F cores.
Typical usage of these commands could look something like
targets uscale.axi
boot_pmu /path/to/pmu-firmware.bin
boot_apu /path/to/u-boot-spl.bin
But of course there is always the option to call lower-level commands
individually if your boot process is more unusual.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Change-Id: I816940c2022ccca0fabb489aa75d682edd0f6138
Reviewed-on: https://review.openocd.org/c/openocd/+/8133
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
After 'reset run' or 'reset halt' the loaded application
is expected to manipulate RAMON register to workaround
the known silicon errata.
Moreover, writing to RAMON register from 'reset-end' event
after 'reset run' may collide with application intentions.
Use the workaround in 'reset-init' event only to ensure
correct function of target algorithms.
Change-Id: I7d2d92e6805a05a83676edb46b3163ef39b9a7e4
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/8104
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Use the newer driver name 'nrf5' instead.
While on it set the unused parameters of flash bank
creation to zero.
While on it remove 2 empty comments.
Change-Id: I9cf0eadc5b696e6c8b7e6aec0ea3345967523e87
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/8103
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
- Example for configuring multiple non-SMP
Xtensa cores e.g. for heterogeneous debug
- JTAG only at this time; DAP out of scope
- Dual-Xtensa Palladium example via VDebug
- Update Xtensa core config examples
Signed-off-by: Ian Thompson <ianst@cadence.com>
Change-Id: I6d2b3d13fa8075416dcd383cf256a3e8582ee1c1
Reviewed-on: https://review.openocd.org/c/openocd/+/8078
Tested-by: jenkins
Reviewed-by: Jacek Wuwer <jacekmw8@gmail.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
This change implements the support for the ARM Debug Interface v6.
The DAP-level interface properly selects the DP Banks and AP address.
Sample ARM configuration DAP and JTAG scripts have been updated.
Change-Id: I7df87ef764bca587697c778810443649a7f46c2b
Signed-off-by: Jacek Wuwer <jacekmw8@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8067
Tested-by: jenkins
Reviewed-by: Ian Thompson <ianst@cadence.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
S32K General-Purpose Microcontrollers
Scalable, low-power Arm® Cortex®-M series-based microcontrollers AEC-Q100
qualified with advanced safety and security and software support for
industrial and automotive ASIL B/D applications in body, zone control,
and electrification.
Change-Id: I4143258535437c18b81802436267bfd561de9d31
Signed-off-by: David Vidrie Leon <davidvidrie@geotab.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8012
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Tested with APM32F103CBT6 using JTAG and SWD transport. All flash
operations, including sector and device protection, work as expected.
Change-Id: Ibefe1a65d710aea87b86ab7ff8a4153512a0ea4f
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8017
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested with APM32407RGT6 using JTAG and SWD transport. All flash
operations, including sector and device protection, work as expected.
Revision identifier (0x0009) is not updated due to missing documentation.
Change-Id: I33f4630fd00096656369ecc923aea2dcad77c7d3
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8016
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested with APM32F030C8T using SWD transport. All flash operations,
including sector and device protection, work as expected.
Revision identifier (0x0011) is not updated due to missing documentation.
Introduce a new directory structure that contains the manufacturer for
the sake of clarity.
Change-Id: I679387943b09fef640f8f8b6904e542f4e4b29aa
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8015
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
This has a quite complex JTAG router chain requiring both a custom
BYPASS instruction to access child taps, and JTAG configuration to
enable individual DAP nodes.
Change-Id: I6f5345764e1566d70c8526a7e8ec5d250185bd2c
Signed-off-by: Henrik Nordström <henrik.nordstrom@addiva.se>
Reviewed-on: https://review.openocd.org/c/openocd/+/8042
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Add support for the TI K3 family J722S SoC. This SoC is a variant of
AM62P chassis with a different JTAG ID, additional R5 added in (along
with C7x and few other peripheral changes). Reuse existing definition.
For further details, see https://www.ti.com/lit/zip/sprujb3
Change-Id: I754e6be8df3a26212437ea955f6a791d7c99b0c8
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8049
Reviewed-by: Bryan Brattlof <hello@bryanbrattlof.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
The target supports both SWD and JTAG, but the existing cfg file
only supports JTAG. Using the standard [using_jtag] mechanism,
the user would now have a choice.
Change-Id: Ic6adb68090422812d591f6bf5b945ac10f323c74
Signed-off-by: Peter Lawrence <majbthrd@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8020
Reviewed-by: Jörg Wunsch <openocd@uriah.heep.sax.de>
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
On this chip, the ndmreset bit in the RISC-V debug module doesn't
trigger a system reset like it should. To work around this, add a custom
"reset-assert" handler in its config file that resets the system by
writing to memory-mapped registers.
I've tested this workaround on a Sipeed Longan Nano dev board with a
GD32VF103CBT6 chip. It works correctly for both "reset run" and "reset
halt" (halting at pc=0 for the latter).
I originally submitted[1] this workaround to the riscv-openocd fork of
OpenOCD. That fork's maintainers accepted it, but have not upstreamed it
like they have several other of my changes.
[1] https://github.com/riscv/riscv-openocd/pull/538
Change-Id: I7482990755b300fcbe4963c9a599d599bc02684d
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/6957
Tested-by: jenkins
Reviewed-by: zapb <dev@zapb.de>
Add support for the TI K3 family AM273 SoC.
For further details, see https://www.ti.com/lit/pdf/spruiu0
Change-Id: Ifa21d0760831f4f525ecd976fb8d086ffdbc9e9f
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7950
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Add support for the TI K3 family AM263 SoC.
For further details, see https://www.ti.com/lit/pdf/spruim2
Change-Id: I9a91b3d675511661dfc2710a7183bd59b98da133
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7948
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Add support for the TI K3 family AM243 SoC. This SoC is built on the
same base of AM642, so reuse the configuration with the exception of
Cortex-A53 which is not available on this device.
For further details, see https://www.ti.com/lit/pdf/spruim2
Change-Id: I971ba878b0f503e5120f6853634776eb61d05080
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7946
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Sort the documentation for the TI K3 parts alphabetically.
Change-Id: I2c40714ad590e3d9232a6f915c157d677e0c3610
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7945
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
The AM2x family of K3 SoCs typically do not contain a Cortex-A53 or
A72 processor. So, make the cpu "up" functions available when armv8
processor count > 0.
Change-Id: I985b194fe7cc63e4134ad84ccd921cc456eb412f
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7944
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Evgeniy Naydanov
Marek Kraus
MicBiso
Antonio Borneo
liangzhen
Jiafei Pan
Alexandre Bailon
Marek Vasut
Parshintsev Anatoly
Nishanth Menon
Marc Schink
Tomas Vanek
Noah Moroze
Sean Anderson
Dominik Wernberger
Ian Thompson
Jacek Wuwer
David Vidrie Leon
Henrik Nordström
Tim Newsome
Peter Lawrence
Thomas Hebb