flash/stm32l4x: fix flash programming in 64-bit hosts
stm32l4_work_area struct is shared between the loader and stm32l4x flash driver
'*wp' and '*rp' pointers' size is 4 bytes each since stm32l4x devices have
32-bit processors.
however when used in openocd code, their size depends on the host
if the host is 32-bit, then the size is 4 bytes each.
if the host is 64-bit, then the size is 8 bytes each.
to avoid this size difference, change their types depending on the
usage (pointers for the loader, and 32-bit integers in openocd code).
Change-Id: I0a3df4bb4bf872b01cdb9357eb28307868d7d469 Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6556 Tested-by: jenkins Reviewed-by: Yestin Sun <sunyi0804@gmail.com> Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tarek BOCHKATI [Sun, 29 Aug 2021 15:33:55 +0000 (16:33 +0100)]
flash/stm32l4x: fix segmentation fault with HLA adapters and STM32WLx devices
CPU2 (Cortex-M0+) is supported only with non-hla adapters because it is on AP1.
Using HLA adapters armv7m.debug_ap is null, and checking ap_num triggers
a segfault.
flash/nor/tcl: fix the flash name returned by 'flash list' command
The 'flash list' command returns the driver name as flash name which seems
to be incorrect, the proposal is:
- to fix this by returning the flash name
- and add a new item 'driver' in the returned list
example:
before the change
> flash list
{name stm32l4x base 134217728 size 0 bus_width 0 chip_width 0}
{name stm32l4x base 201326592 size 0 bus_width 0 chip_width 0}
{name stm32l4x base 200933376 size 0 bus_width 0 chip_width 0}
after the change
> flash list
{name stm32l5x.flash_ns driver stm32l4x ...}
{name stm32l5x.flash_alias_s driver stm32l4x ...}
{name stm32l5x.otp driver stm32l4x ...}
This version of jimtcl:
- fixes memory leak in API Jim_CreateCommand();
- fixes 'make distcheck';
- uses single-argument syntax for 'expr'.
With the 'expr' syntax already fixed in all the tcl scripts in
OpenOCD, let's use the latest jimtcl to check it and anticipate
any further issues.
By using this version, the workaround for the memory leak and for
distcheck can be reverted.
Antonio Borneo [Sun, 29 Aug 2021 23:01:40 +0000 (01:01 +0200)]
openocd: prepare for jimtcl 0.81 'expr' syntax change
Jimtcl commit 1843b79a03dd ("expr: TIP 526, only support a single
arg") drops the support for multi-argument syntax for the TCL
command 'expr'.
All the scripts distributed with OpenOCD are already compliant
with the new syntax.
To avoid breaking user script, introduce a replacement for 'expr'
command that handles the old syntax while issuing a deprecated
warning.
This change should be part of OpenOCD v0.12.0, then reverted.
Tarek BOCHKATI [Fri, 26 Mar 2021 14:07:41 +0000 (15:07 +0100)]
flash/stm32l4x: add support of STM32WB1x
STM32WB1x devices has a single flash bank up to 320 KB (page 2KB)
note: STM32WB5x/WB3x are single banks as well but do have 4KB as page size.
note: remove the assert that checks if max_mages is power of two, because
STM32WB1x flash size is not a power of 2
Tarek BOCHKATI [Sat, 6 Mar 2021 21:46:35 +0000 (22:46 +0100)]
flash/stm32l4x: switch to to c loader instead of assembly loader
switching to C loader instead of the assembly version will enhance readability
will reduce the maintenance effort.
besides the switch to C loader, we added a new parameters to the loader
like flash_word_size and flash_sr_bsy_mask in order to support properly
STM32U5x and STM32G0Bx/G0Cx in dual-bank mode.
Tarek BOCHKATI [Tue, 17 Aug 2021 12:29:56 +0000 (13:29 +0100)]
server/telnet: support 'CTRL+C'
like in terminal 'CTRL+C':
- keeps the line content so the user can refer to it (like copy/paste)
- marks the line with '^C', as hint that the command was not executed
- permit the user to write a new command
Antonio Borneo [Sat, 15 May 2021 21:14:18 +0000 (23:14 +0200)]
Makefile: drop warning suppression on win build
Commit dcdf71c21b99 ("- fix signed/unsigned build errors under
win32. Thanks Zach Welch <zw@superlucidity.net>") in 2009 prevents
gcc warnings on sign/unsigned comparisons while building for Win
on folders 'helper' and 'server'.
In 2011, commit b69119668ed8 ("RTOS Thread awareness support wip")
uses the same method on the new folder 'rtos'.
In mean time, all the incorrect sign/unsigned comparisons has been
fixed and no warning is present with the default -Wextra flag that
implies -Wsign-compare.
The comment:
# FD_* macros are sloppy with their signs on MinGW32 platform
seems linked to some old implementation of MinGW32 include file
that doesn't apply on current versions.
Remove the obsolete hacks to suppress the warnings.
Antonio Borneo [Sat, 15 May 2021 22:48:49 +0000 (00:48 +0200)]
helper: remove fix for libusb pre-v1.0.9
Libusb v1.0.9 has been released on April 2012. We can reasonably
expect that every user has already updated his system to a libusb
newer of equel to v1.0.9.
Tarek BOCHKATI [Tue, 16 Mar 2021 15:10:59 +0000 (16:10 +0100)]
flash/stm32l4x: add support of STM32U57x/U58x
this device flash registers are quite similar to STM32L5
with this changes :
- flash size is up to 2MB
- 2MB variants are always dual bank
- 1MB and 512KB variants could be dual bank (contiguous addressing)
depending on DUALBANK bit(21)
- flash data width is 16 bytes (quad-word)
Tarek BOCHKATI [Thu, 4 Feb 2021 21:43:52 +0000 (22:43 +0100)]
flash/stm32l4x: add support of STM32WL5x dual core
according the RM0453, the second core have a different Flash CR and SR
registers for flash operations (called C2CR and C2SR).
so we need to a different flash_regs than older L4 devices.
@see stm32wl_cpu2_flash_regs
the C2CR register don't contain LOCK and OPTLOCK bits, and this explain
the addition of new register index called STM32_FLASH_CR_WLK_INDEX to
look-up the CR with lock, to be used in locking/unlocking the flash.
note: DBGMCU_IDCODE cannot be read using CPU1 (Cortex-M0+) at AP1,
to solve this read the UID64 (IEEE 64-bit unique device ID register)
flash/stm32l4x: prevent undefined behavior warnings caused by signed integer operations
When running OpenOCD with -fsanitize=undefined, a warning is emitted
for an bit-shifting operation whose result cannot be stored in a
signed integer.
This is because (1 << 31) overflows a signed integer, which is
undefined behavior. By making each of the bit masks act on an
unsigned number, the warning is avoided.
Whether this warning emitted by UBSan would ever manifest into a real
error is debatable, but fixing this does make UBSan happy.
Tarek BOCHKATI [Tue, 19 Jan 2021 12:26:48 +0000 (13:26 +0100)]
flash/stm32l4x: add support of STM32G0Bx/G0Cx devices
this device has a dual bank flash architecture up to 512 KB (page 2KB)
reference: RM0444 Rev 5
notes:
- 128k variant is always single bank
- 256k variant flash is contiguous (no gap) in dual bank mode
- BKER is bit 13 vs bit 11 for other devices
> added cr_bker_mask in stm32l4_flash_bank struct
- BSY2 for bank 2 operations
> added sr_bsy_mask in stm32l4_flash_bank struct
> proposed optimization: always wait for (BSY1 | BSY2) with
STM32G0Bx/G0Cx devices only (for L4+ devices BSY2=PEMPTY)
TODO: update flashloader to use the proper BSY bits
temporarily don't use the loader in dual bank mode
This struct element is replaced by the usage of F_HAS_L5_FLASH_REGS flag:
since over this driver stm32l4_flash_regs is the default register layout,
and the only exception is STM32L5 family,
so it's simpler to manage it using a flag.
Note: the same flag will be used with STM32U5 devices, as they have
the same registers layout, which explains the move of stm32l5_s_flash_regs
before the switch(device_id) in order to not re-write this for STM32U5.
Tarek BOCHKATI [Fri, 22 Jan 2021 12:15:52 +0000 (13:15 +0100)]
flash/stm32l4x: STM32L5 support programming when TZEN=1 and RDP=0x55
when RDP level is 0.5 the provided work-area should reside in non-secure RAM
to ensure that:
- add a hint in the driver level
- reduce the usage of secure RAM only when TZEN=1 and RDP is not 0.5
(check the target configuration file)
flash/stm32l4x: do not report bank mode before probing [FIX]
in line 1391, get_stm32l4_bank_type_str(bank) will always output the same
value "Flash single" since the variable stm32l4_info->dual_bank_mode is false
by default, stm32l4_info->dual_bank_mode will be set correctly afterward
in the switch case at line 1467
thus the need to remove the usage of get_stm32l4_bank_type_str(bank) before
stm32l4_info->dual_bank_mode initialization.
Fixes: 64c2e03b23d9 ("flash/nor: improved API of flash_driver.info & fixed buffer overruns")
Change-Id: Ia8dc7e144e0ded6143682eb514c247f27859ff81 Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6411 Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com> Tested-by: jenkins
root [Thu, 3 Jun 2021 09:37:37 +0000 (11:37 +0200)]
target/adi_v5_jtag: Add support for 8-bit IR JTAG-DP
As per Arm Debug Interface Architecture Specification (ADIv5.0 to
ADIv5.2), B3.3.1, the JTAG-DP as an IR length of 4 or 8 bits
depending on the ARM implementation. The current code
only support 4-bit and this patch extends the support to 8-bit IR.
Not tested back yet on a 4-bit target.
Change-Id: Ie4f875dc336caf014c6cfced57574b54d0970623 Signed-off-by: Antoine C. <acalando@free.fr>
Reviewed-on: https://review.openocd.org/c/openocd/+/6285 Tested-by: jenkins Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Antonio Borneo [Sun, 8 Aug 2021 11:51:33 +0000 (13:51 +0200)]
jep106: use packed jedec manufacturer code
JEP106 encodes JEDEC-assigned manufacture code as:
a) a sequence of zero or more escape codes 0x7f;
b) an odd-parity bit of the next 7 bits;
c) 7 bits.
The same code is often represented as a single value composed by
the logical OR between:
- the number of escape codes in a), shifted left by 7 positions;
- the 7 bits in c).
This is the preferred packed representation used by this change.
Currently there are only two uses of JEP106 in openocd to get the
manufacturer name:
- to decode the JTAG IDCODE of each TAP, where the JEP106 code is
already packed as in the preferred representation above in bits
IDCODE[11:1];
- to decode the ARM CoreSight PIDR register, where the JEP106 code
is split in 3 parts:
= PIDR3[3:0], corresponding to bits [10:7] of the packed code;
= PIDR2[2:0], corresponding to bits [6:4] of the packed code;
= PIDR1[7:4], corresponding to bits [3:0] of the packed code.
Wrap the existing JEP106 decode function in a simpler API using
the packed code.
Simplify the callers by skipping the bit unpacking.
Change the manufacturer code in CoreSight table dap_partnums[] to
match the packed representation, by removing the always-one bit 7
erroneously taken from PIDR bit JEDEC and included in the former
table.
Change-Id: I63eb4da9e6801fab25e330f1f6b792d2fd619493 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6418 Tested-by: jenkins
Antonio Borneo [Wed, 11 Aug 2021 15:03:18 +0000 (17:03 +0200)]
arm_adi_v5: update coresight class names
Update the list of ARM coresight classes wrt to latest ARM
documentation.
Use c99 array designator to easily track changes in future.
Add a comment for the entry "OptimoDE DESS". It was added in 2009
by David Brownell, but Google cannot find any reference other than
this line in openocd code its associated commit. It should not be
an issue keeping it as is.
Change-Id: Ia3b646131ee68ca5263095c3a0aeaf75c004b324 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6431 Tested-by: jenkins
Antonio Borneo [Wed, 11 Aug 2021 22:14:29 +0000 (00:14 +0200)]
command: log the command only when it is executed
In case of multi-word commands, the command dispatcher is nested
called at each word during command name parsing.
The improper position of the call to script_debug() causes the
command line to be logged once at each parsed word.
In the example of command "cpu arm disassemble 0" the full command
is logged three times for "cpu", "arm" and "disassemble":
Debug: 656617 61843 command.c:201 script_debug(): command - cpu arm disassemble 0
Debug: 656618 61843 command.c:201 script_debug(): command - cpu arm disassemble 0
Debug: 656619 61843 command.c:201 script_debug(): command - cpu arm disassemble 0
Call script_debug() only when the parsing is terminated and the
command handler is going to be executed.
Antonio Borneo [Fri, 13 Aug 2021 16:52:20 +0000 (18:52 +0200)]
cortex_m: fix command 'step address'
The command 'step' accepts an optional parameter 'address' to run
the step-by-step execution from an address different from current
program counter.
When OpenOCD sets the new program counter value in the register
cache, it doesn't flag it as dirty. The following call to function
armv7m_restore_context() does not propagate the new value of the
program counter to the target. This cause the target to continue
from the old program counter value, ignoring the user's request.
It is hard to notice the issue if the target is halted in an idle
loop! In fact the default mode to operate step-by-step is to set a
breakpoint to the following instruction and resume execution. In
the idle loop the CPU will pass through the breakpoint whatever
the resume address is. User will find the target halting at the
instruction following 'address' which is consistent with the
expected behaviour of command 'step address'.
To verify the issue on an STM32F4, use a dummy code in SRAM:
halt
mww 0x20000000 0xbf00bf00
mww 0x20000004 0xbf00bf00
mww 0x20000008 0xe7fcbf00
arm disassemble 0x20000000 6
0x20000000 bf00 nop
0x20000002 bf00 nop
0x20000004 bf00 nop
+--> 0x20000006 bf00 nop
| 0x20000008 bf00 nop
+-<- 0x2000000a e7fc b #0x20000006
resume 0x20000006
halt
step 0x20000000
the target doesn't halt because it is in the loop from 0x20000006
to 0x2000000a. The 'step 0x20000000' did not changed the program
counter so the temporary breakpoint at 0x20000002 is never hit.
Then:
halt
step 0x20000008
target halted ...
... pc: 0x2000000a
gives the feeling that only the instruction at 0x20000008 has been
executed, but actually the whole loop has been executed from the
place 'halt' stopped the execution till the breakpoint at the
instruction following 0x20000008.
Flag the program counter cached value as 'valid' and 'dirty' to
force armv7m_restore_context() to update the target's register.
Change-Id: I49bd8bb95b2f5429ec38ed016f2ad706618ae68a Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6434 Tested-by: jenkins Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Antonio Borneo [Thu, 19 Aug 2021 14:07:21 +0000 (16:07 +0200)]
stlink: fix SWIM mode on stlink-v3
Commit 89f07325f2e7 ("stlink: Set speed before entering JTAG/SWD
mode") anticipates setting the adapter speed just before entering
in the JTAG/SWD mode. This to initiate the communication with the
speed selected by the user.
But SWIM doesn't allow setting the speed before entering in SWIM
mode. The resulting error causes OpenOCD to quit.
The problem only happens with stlink-v3, due to the different way
to set the adapter speed on different stlink versions.
Set the speed before entering in the mode only for JTAG and SWD
modes.
Change-Id: Iab42cd9d72ecfac14c7e17bae74e0dee2218b235 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com> Fixes: 89f07325f2e7 ("stlink: Set speed before entering JTAG/SWD mode")
Reviewed-on: https://review.openocd.org/c/openocd/+/6443 Tested-by: jenkins Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
rtos/riot: fix out-of-bounds writes when target is corrupted
This protects against out-of-bounds writes when the memory
of RIOT's scheduler is corrupted.
This memory can be corrupted because of:
- Programming errors
- The scheduler not yet having been initialised
- An incorrect symbol file being used during debugging.
This error can result in OpenOCD segfaulting. Valgrind was
used to find the approximate location of the error.
Change-Id: I60e7d7c245b8c4e38f4c98cb0c0347a9b5ec3177 Signed-off-by: Sebastiaan de Schaetzen <sebastiaan.de.schaetzen@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6381 Tested-by: jenkins Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Antonio Borneo [Mon, 9 Aug 2021 13:03:37 +0000 (15:03 +0200)]
jtag/mpsse: fix SIGSEGV for use after free
By pressing CTRL-C on a running openocd with FTDI adapter, it's
possible to generate a segmentation fault that with valgrind is
dumped as a SIGABRT:
^CError: libusb_handle_events() failed with LIBUSB_ERROR_INTERRUPTED
==16594== Invalid read of size 8
==16594== at 0x48B2472: libusb_submit_transfer
==16594== by 0x48B4B0F: libusb_control_transfer
==16594== by 0x1A6B9D: mpsse_purge (mpsse.c:428)
==16594== by 0x1A7B96: mpsse_flush (mpsse.c:953)
==16594== by 0x19BA5B: ftdi_execute_queue (ftdi.c:654)
...
==16594== Address 0x6158568 is 72 bytes inside a block of size 216 free'd
==16594== at 0x484118B: free (vg_replace_malloc.c:755)
==16594== by 0x1A7B88: mpsse_flush (mpsse.c:950)
==16594== by 0x19BA5B: ftdi_execute_queue (ftdi.c:654)
...
==16594== Block was alloc'd at
==16594== at 0x48435FF: calloc (vg_replace_malloc.c:1117)
==16594== by 0x48B2259: libusb_alloc_transfer
==16594== by 0x1A7A26: mpsse_flush (mpsse.c:880)
==16594== by 0x19BA5B: ftdi_execute_queue (ftdi.c:654)
...
==16594== Process terminating with default action of signal 6 (SIGABRT):
dumping core
...
Aborted (core dumped)
The error is in mpsse_flush() that, following valgrind dump:
- allocates the buffer at line mpsse.c:880
read_transfer = libusb_alloc_transfer(0);
- frees the buffer at line mpsse.c:950
libusb_free_transfer(read_transfer);
- still pretends to use the freed buffer at line mpsse.c:953
mpsse_purge(ctx);
Move the call to mpsse_purge() right before freeing the buffer.
Change-Id: I47c71ec8c283f4b037fdd7cd72ca2e877cd3a851 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/6417 Tested-by: jenkins
Antonio Borneo [Wed, 4 Aug 2021 22:37:32 +0000 (00:37 +0200)]
arm_adi_v5: use macro DP_APSEL_MAX in place of magic number
Commit 11019a824d02 ("adi_v5: enforce check on AP number value")
introduces the macro DP_APSEL_MAX and use it in place of hardcoded
magic numbers for the upper limit of AP selection value.
Fix one more place where the macro should be used.
Change-Id: I6c57f72405c69bbb40924221309d95dfeb5f7540 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com> Fixes: 11019a824d02 ("adi_v5: enforce check on AP number value")
Reviewed-on: http://openocd.zylin.com/6415 Reviewed-by: Tomas Vanek <vanekt@fbl.cz> Tested-by: jenkins Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Antonio Borneo [Thu, 5 Aug 2021 15:08:11 +0000 (17:08 +0200)]
arm_adi_v5: fix access to 64-bit MEM-AP
Commit ac22cdc57322 ("target/adiv5: Large Physical Address
Extension") reads the register MEM_AP_REG_CFG and keeps it in a
new field of struct adiv5_ap. The test on LE bit (Large Extension)
is used to identify if mem_ap addresses are 32 or 64 bits.
But the register MEM_AP_REG_CFG is only read during mem_ap_init(),
that is called only when the AP is used as a target debug AP or if
a target mem_ap is attached to that AP.
The openocd commands '<dapname> baseaddr', '<dapname> info' and
'dap info' can be executed on AP that has not been associated yet
to a target, thus executed without any knowledge of MEM_AP_REG_CFG
value. The initialization to ADI_BAD_CFG causes openocd to always
use 32 bit mode on un-associated APs.
Verify if MEM_AP_REG_CFG has not been read and eventually read it.
In case of 32 bits mode AP, MEM_AP_REG_BASE64 is defined as 'RES0'
(reserved, but readable); the code can queue both the read of
MEM_AP_REG_CFG and MEM_AP_REG_BASE64, before knowing if the former
is required. This speeds-up the operation.
Rename ADI_BAD_CFG as MEM_AP_REG_CFG_INVALID.
Change-Id: If3bbd792b56a483022c37ccc2ce82b5ba5c36caa Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com> Fixes: ac22cdc57322 ("target/adiv5: Large Physical Address Extension")
Reviewed-on: http://openocd.zylin.com/6412 Tested-by: jenkins Reviewed-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Antonio Borneo [Wed, 4 Aug 2021 10:25:18 +0000 (12:25 +0200)]
arm_adi_v5: fix signed offset in Class 0x1 ROM tables
In both arm ADIv5 and ADIv6 documentation, for both Class 0x1 and
Class 0x9 ROM tables, the offset field from ROM tables is supposed
to be a signed value: "Negative values of OFFSET are permitted,
using two’s complement."
The commit ac22cdc57322 ("target/adiv5: Large Physical Address
Extension") extends to 64 bits the addresses while managing the ROM
tables. The offset is read as unsigned and in the former 32 bits
implementation the wrap-around was hiding the need for converting
the offset to signed. The new implementation requires the proper
cast to the offset.
On a STM32F411, without this fix the ROM table dump is incorrectly
reporting addresses out of the 32 bit bus range:
MEM-AP BASE 0xe00ff003
Valid ROM table present
Component base address 0xe00ff000
Peripheral ID 0x00000a0411
Designer is 0x0a0, STMicroelectronics
Part is 0x411, Unrecognized
Component class is 0x1, ROM table
MEMTYPE system memory present on bus
ROMTABLE[0x0] = 0xfff0f003
Component base address 0x1e000e000
^^^^^^^^^^^
Cast the offset before adding it to the base address of the ROM
table.
Change-Id: I8d31fd2b3d657286cb96f8e22fb00842baa728f7 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com> Fixes: ac22cdc57322 ("target/adiv5: Large Physical Address Extension")
Reviewed-on: http://openocd.zylin.com/6410 Tested-by: jenkins Reviewed-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Jan Matyas [Fri, 23 Jul 2021 05:29:56 +0000 (07:29 +0200)]
.github/workflows: Add missing 'apt-get update' to the snapshot workflow
During the build of the OpenOCD snapshot via GitHub Actions, ensure that
the local package database is first updated, prior to installing any
packages via apt-get install. Otherwise the apt-get install could fail.
Change-Id: If3c29faeb1496d5e2be75350f6352575b1f3a42e Signed-off-by: Jan Matyas <matyas@codasip.com>
Reviewed-on: http://openocd.zylin.com/6378 Reviewed-by: Xiaofan <xiaofanc@gmail.com> Tested-by: jenkins Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com> Reviewed-by: Tim Newsome <tim@sifive.com> Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Jian-Hong Pan [Sun, 11 Jul 2021 04:54:39 +0000 (12:54 +0800)]
tcl/board: Add Raspberry Pi 4 model B board
OpenOCD cannot connect to BCM2711's JTAG interface on RPi 4B board until
the reset configuration mode is set as trst_only.
According to Table 94. GPIO Pins Alternative Function Assignment of
Broadcom's BCM2711 ARM Peripherals datasheet [1] and Raspberry Pi's GPIO
control in config.txt document [2], only Test Reset (TRST) pin (no
System Reset, SRST) is exposed.