Commit Graph

8828 Commits

Author SHA1 Message Date
Antonio Borneo
b5e015357a mips_mips64: fix minor host endianness bug
Commit 80f1a92bd7 ("mips64: Add generic mips64 target support")
adds a log of the target's program counter in function
mips_mips64_debug_entry() by directly casting the little-endian
buffer in pc->value.
This is going to print an incorrect value on big-endian hosts.

Use the function buf_get_u64() to return the register value.

Not tested on real HW. Issue identified with GCC compiler flag
'-Wcast-align=strict' after change http://openocd.zylin.com/5937/
("target/register: use an array of uint8_t for register's value").

Change-Id: Icbda2b54a03fdec287c804e623f5db4252f9cd2a
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Fixes: 80f1a92bd7 ("mips64: Add generic mips64 target support")
Reviewed-on: http://openocd.zylin.com/5944
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
2020-12-05 23:18:33 +00:00
Antonio Borneo
a56b729191 arm7_9_common: fix host endianness bug in arm7_9_full_context()
The original code passes to ->read_core_regs() and to
->read_xpsr() the pointer to the little-endian buffer reg.value.
This is incorrect because the two functions above require a
pointer to uint32_t, since they already run the conversion with
arm_le_to_h_u32() in the jtag callback.
This causes a mismatch on big-endian host and the registers get
read with the incorrect endianness.

Use an intermediate buffer to read the registers as uint32_t and
to track the destination reg.value pointer, then copy the value in
reg.value after the call to jtag_execute_queue().

Tested with qemu-armeb and an OpenOCD built through buildroot
configured for cortex-a7 big-endian.

Note that if jtag_execute_queue() fails, the openocd register
cache is not updated, so the already modified flags 'valid' and
'dirty' are incorrect. This part should be moved after the call to
jtag_execute_queue() too.

Change-Id: Iba70d964ffbb74bf0860bfd9d299f218e3bc65bf
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5943
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
2020-12-05 23:18:29 +00:00
Antonio Borneo
62686ab161 armv4_5: fix output of command 'arm reg'
Commit fc2abe63fd ("armv7m: use generic arm::core_mode") adds
two special modes for ARMv6M and ARMv7M in struct arm_mode_data[].
While these modes do not have any additional register to be dumped
by command 'arm reg', the command still prints an header for these
modes but not followed by any register.

Detect the special modes for ARMv6M and ARMv7M and skip them to
avoid printing the useless header.

Change-Id: I04145769e5742624f143c910eebf9a6f6d8e3cdc
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Fixes: fc2abe63fd ("armv7m: use generic arm::core_mode")
Reviewed-on: http://openocd.zylin.com/5942
Tested-by: jenkins
2020-12-05 23:18:22 +00:00
Antonio Borneo
693b8501e5 armv4_5: fix segmentation fault in command 'arm reg'
Commit fed7131049 ("armv4_5: support weirdo ARMv6 secure monitor
mode") introduces the secure mode 28 of ARMv6 as a synonymous of
mode 22 (MON), but does not add it in the switch/case in command
'arm reg'.
When command 'arm reg' scans the array arm_mode_data[] on targets
without secure modes, it does not detect the new secure mode as
not supported by the architecture, thus triggers a segmentation
fault when it try to read the register's value from unallocated
memory.
Issue detected with target arm926ejs.

Add the new mode in the switch/case and treat it as the mode MON.

Change-Id: I2b72cc558e097879a7ee6ea601200bfda6b60270
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Fixes: fed7131049 ("armv4_5: support weirdo ARMv6 secure monitor mode")
Reviewed-on: http://openocd.zylin.com/5941
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
2020-12-05 23:18:15 +00:00
Boran Car
ba58d90f6f jep106: Add new IDs from JEDEC
From JEP106AZ, released on May 24, 2019.

Change-Id: I768b7077ec6abcd19ae1530b5715c7ea993add67
Signed-off-by: Boran Car <boran.car@hex-five.com>
Reviewed-on: http://openocd.zylin.com/5244
Tested-by: jenkins
Reviewed-by: Jonathan McDowell <noodles-openocd@earth.li>
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Jiri Kastner <cz172638@gmail.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
2020-12-05 23:17:48 +00:00
Marc Schink
7b641d3d4e Add initial RTT support
Real Time Transfer (RTT) is an interface specified by SEGGER based on
basic memory reads and writes to transfer data bidirectionally between
target and host.
Every target that supports so called "background memory access", which
means that the target memory can be accessed by the debugger while the
target is running, can be used.

RTT is especially of interest for targets which do not support Serial
Wire Output (SWO) (e.g. ARM Cortex-M0) or where using semihosting is
not possible (e.g. real-time applications) [1].

The data transfer is organized in channels where each channel consists
of an up- and/or down-channel. See [2] for more details.

Channels are exposed via TCP connections. One or more RTT server can be
assigned to each channel to make them accessible to an unlimited number
of TCP connections.

The current implementation does not respect buffer flags which are used
to determine what happens when writing to a full buffer.

Note that the implementation is designed in a way that the RTT
operations can be directly performed by an adapter (e.g. J-Link).

[1] https://devzone.nordicsemi.com/tutorials/6/
[2] https://www.segger.com/jlink-rtt.html

Change-Id: I8bc8a1b381fb74e08b8752d5cf53804cc573c1e0
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: http://openocd.zylin.com/4055
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
2020-12-02 23:15:52 +00:00
Tomas Vanek
d459a2d27d adi_v5_swd: wait for readable DPIDR, ABORT if stalled
Reading of DPIDR is the very first operation after JTAG to SWD sequence.
Without this change if DPIDR read fails then swd connect fails.

Keep trying JTAG to SWD sequence and DPIDR read until success
or timeout 0.5 sec. It makes setting of adapter srst delay on SWD transport
mostly unnecessary.

Also test for ERROR_WAIT (which should not occur according to
IHI 0031E B4.3.2 but a quirk is known) and if bus is kept stalled
then issue abort to make the next connect possible.

Change-Id: Id8fe6618605bbeb4fed5061e987ed55de90a35f2
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/5730
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
2020-12-02 23:15:16 +00:00
Tomas Vanek
646c3c9902 arm_adi_v5: prevent possibly endless recursion in dap_dp_init()
If dap_dp_read_atomic() in 30 trials loop fails, dap->do_reconnect is set.
Following dap_dp_read_atomic() calls dap_queue_dp_read() which in case
of SWD transport calls swd_queue_dp_read(). It starts
with swd_check_reconnect() and it calls swd_connect() because
dap->do_reconnect is set. swd_connect() does some initialization,
reads DPIDR and calls dap_dp_init() again!

Moreover if dap_dp_init() is called from cortex_m_reset_(de)assert()
one level of recursion is necessary to reconnect the target.

Introduce dap_dp_init_or_reconnect() for use in cortex_m reset
and similar.
Remove loop of 30 atomic reads of DP_STAT to prevent unwanted recursion.

Change-Id: I54052fdefe50bf5f7c7b59fe751fe2063d5710c9
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/5729
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
2020-12-02 23:15:08 +00:00
Tarek BOCHKATI
a8edbd0200 tcl/target: remove deprecated ${target}_${adapter}.cfg files
Change-Id: Ic4837ad3bd06eb353020e44638306f341a923c05
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@st.com>
Reviewed-on: http://openocd.zylin.com/5929
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
2020-11-15 22:11:24 +00:00
Tomas Vanek
a03ac1ba30 helper/command: disable logging of registered commands [RFC]
Every debug log of OpenOCD contains approximately 130 lines like:

Debug: 264 147 command.c:354 register_command_handler(): registering 'flash'...

Because only root name of the command is logged, most of lines is not
too informative. E.g. registering 'flash' is repeated 14 times.

Karl Passon submitted the patch [1] changing the logged cmd name from
root to lowest level. It makes the log better. Unfortunately we also have
'reset_config' and 'cortex_m reset_config' and similar which looks
equal in the log after [1].
Moreover [1] has not been reviewed for 5 years.

So my guess is that nobody uses that crap in debug log.

Save more than 10 kbytes in any debug log and make log analyse easier
by blocking log command in #if 0 block.
If some developer eventually needs to debug cmd registering he can easily
enable logging again.

[1] http://openocd.zylin.com/2765

Change-Id: Ib7e528aadd692fd0da2e3c005b4c5a484551b728
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/5928
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Christopher Head <chead@zaber.com>
2020-11-15 22:10:35 +00:00
Tomas Vanek
6132694036 flash/nor/stm32f1x: fix error message
Backported from gd32vf103.c

Change-Id: I9c5bb7b36e6efcee0473c97047058ef26cc46eb7
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/5927
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
2020-11-15 22:10:02 +00:00
Tarek BOCHKATI
726b0c5928 stm32l4x: cosmetic simplification of get_stm32l4_info
Change-Id: I2542f946f64388d908b1502f869643080fce9f9e
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/5536
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Andreas Bolsch <hyphen0break@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
2020-11-15 21:55:39 +00:00
Tarek BOCHKATI
3d736e0488 flash/stm32l4x: STM32L55/L56xx basic support (non-secure mode)
STM32L5 have 512 Kbytes of Flash memory with dual bank architecture.
STM32L5 flash is quite similar to L4 flash, mainly register names
and offsets and some bits are changed.
NON-SECURE flash is located at 0x8000000 like L4 devices, so no
big change is needed (secure flash will be subject of another change).

Note: flash driver name is set stm32l5x, in order to extend the commands
with specific L5 commands (to manage TZEN for example ...)

Note: this works only when TZEN=0

Change-Id: Ie758abb4aa19a3f29eeb0702d7dcb43992e4c639
Signed-off-by: Michael Jung <mijung@gmx.net>
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/5510
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
2020-11-15 21:55:20 +00:00
Tarek BOCHKATI
dc43ecce5a flash/stm32l4x: introduce table with register offsets
This change is a preparation for STM32L5 support on top of L4 driver
STM32L5 flash is quite similar to L4 flash, mainly register names
and offsets and some bits are changed.

flash_regs table is introduced within stm32l4_flash_bank struct in order
to get correct register offsets, by using the driver internal function
'stm32l4_get_flash_reg_by_index'.

To use efficiently register indexes, stm32l4 _[get|read|write]_flash_reg
functions are surcharged to accept register indexes.

IMPORTANT: stm32l4_write_option is not surcharged, and they always accept
the option register offset.

tested on NUCLEO-G474RE and STM32L4R9I-DISCO

Change-Id: I739d3e97d63b831af6aa569c5629db0000209551
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/5509
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
2020-11-15 21:42:17 +00:00
Tarek BOCHKATI
44cf202ef5 60-openocd.rules: add ULINKplus CMSIS-DAP based adapter
Change-Id: I5935e0a184b8995122d197046ef8fb4e7eefb884
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@st.com>
Reviewed-on: http://openocd.zylin.com/5926
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
2020-11-15 21:39:06 +00:00
Tomas Vanek
0e0283e582 doc: document CMSIS-DAP v2
Change-Id: Ie54e855901c079b456c26a6239177c7678cdcac7
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/5930
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
2020-11-15 21:38:50 +00:00
Antonio Borneo
9c31457875 jtag/drivers/cmsis_dap: fix build with gcc 10.1.0
Avoid multiple definition of cmsis_dap_usb_backend and
cmsis_dap_hid_backend using 'extern'.
Move the prototypes in cmsis_dap.h.
Remove the useless #if/#endif around the prototypes.

Change-Id: I8d73fe148e2155620244bc887d4235e9af530e30
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5790
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
2020-11-15 21:38:29 +00:00
Tomas Vanek
e6770f1ab6 jtag/drivers/cmsis_dap: fix usb bulk connection logic
http://openocd.zylin.com/4831 has following problems in selecting
USB device/interface to connect:
- attempts connection to any device with user class and 2 bulk endpoints
- regardless of cmsis_dap_vid_pid or cmsis_dap_serial setting
  connects to the first suitable device

Distinguish between real match and no filtering cases and use that info
appropriately.

Add debug messages to show why the interface is refused.

Move CMSIS-DAP interface string detection before checking of class/endpoints
to give more understandable debug log in the case the device is refused.

Keep track of reliable matches in both device and interface enumeration.
First search for the interface with CMSIS-DAP in the interface string.
If it fails, chose the first suitable interface.

Change-Id: Ia1aacd5631a9f5c5db580bfb5745ceb6240d61ad
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/5789
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
2020-11-15 21:38:10 +00:00
Mickaël Thomas
8f927d5164 Add CMSIS-DAP v2 support
This change implements CMSIS-DAP v2 which works with raw USB bulk transfers.

The old driver is now split into a generic CMSIS part and a HID backend,
with a new raw USB backend for CMSIS-DAP v2.

New commands:
- cmsis_dap_backend (usb_bulk | hid | auto)
- cmsis_dap_usb interface <interface number>

Change-Id: I4218477b12ccbfe19c9b332321cd21394bf44e30
Signed-off-by: Mickaël Thomas <mickael9@gmail.com>
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4831
Tested-by: jenkins
2020-11-15 21:36:56 +00:00
Tomas Vanek
b1f488ec1e target/armv7m, cortex_m: fix misleading comments
Change-Id: I4fea29f07f4d3b8b2578b538ef0eef5f1eea285f
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/5876
Tested-by: jenkins
Reviewed-by: Christopher Head <chead@zaber.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
2020-11-15 21:09:08 +00:00
Tomas Vanek
608299484d flash/nor/psoc6: remove setting of xPSR.T bit from sromalgo_prepare()
PSoC6 erases flash to 0x00 not more common 0xff, so a device
with erased flash loads xPSR.T=0 from the zeroed reset vector.
Wrong thumb bit value caused a target algorithm failed with HardFault.
The low level write to xPSR solved the problem only if xPSR cached
copy was not marked dirty.

Later commit 49bd64347a fixed T setting
for all Cortex-M target algorithms.

Since 49bd64 this part of code is useless as xPSR target_start_algorithm()
sets always xPSR dirty so the effect of the low level write is eliminated
(and proper setting of thumb bit is ensured in target_start_algorithm())

Change-Id: I68aea5e921fbc6203f2fe91a45f10d22869327de
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/5875
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
2020-11-15 21:08:56 +00:00
Tomas Vanek
f32ca2d25d target/cortex_m: remove wrong xPSR.ICI/IT bits handling
If a Cortex-M (not M0, M0+) target was stopped in the middle of
a conditional IT block or in the load/store multiple instruction,
cortex_m_debug_entry() used wrong xPSR bits to detect it and then
cleared 8 bits of the exception number from xPSR
- probably wrong bit mask again.

I believe clearing of the ICI/IT bits in cortex_m_debug_entry() has no
reason as Cortex-M does not use instruction injecting.

Remove the wrong code.

The change was originally a part of http://openocd.zylin.com/4862
It is now re-submitted as #4862 is not ready.

Change-Id: If91cd91d1b81b2684f7d5f10cf20452cde1a7f56
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/5874
Tested-by: jenkins
Reviewed-by: Christopher Head <chead@zaber.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
2020-11-15 21:08:41 +00:00
Tomas Vanek
fc91936be7 target/armv7m: use arch_info[i].value instead of allocated memory
Change-Id: I9422cab484d0769404516947e16da1baa001a4e0
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/5328
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
2020-11-15 21:08:26 +00:00
Antonio Borneo
d811d2838b cortex_m: use the new enum ARMV7M_REGSEL_name
Register xPSR is indexed directly with its value 16 or with the
incorrect enum ARMV7M_xPSR.

Replace them with the new enum ARMV7M_REGSEL_xPSR.

Change-Id: I86600e7f78e39002ce45f66d4792d5067c1f541b
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5873
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
2020-11-15 21:08:14 +00:00
Antonio Borneo
4d336e8ffb stlink: handle read/write FPU registers in HLA API
Old stlink firmware in stlink V1 and stlink V2 pre-J15 do not
handle FPU registers in the read_reg() and write_reg() API.

Add code to be compatible with the new API of OpenOCD.

Change-Id: Ib0439c5294b6911ea75efe8c7fa085b014317a4b
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5883
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
2020-11-15 21:07:23 +00:00