diff --git a/doc/openocd.texi b/doc/openocd.texi index 9a5ab9a18..0df25406f 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -4906,6 +4906,7 @@ And two debug interfaces cores: @item @code{testee} -- a dummy target for cases without a real CPU, e.g. CPLD. @item @code{xscale} -- this is actually an architecture, not a CPU type. It is based on the ARMv5 architecture. +@item @code{xtensa} -- this is a generic Cadence/Tensilica Xtensa core. @end itemize @end deffn @@ -10935,33 +10936,150 @@ OpenOCD supports debugging STM8 through the STMicroelectronics debug protocol SWIM, @pxref{swimtransport,,SWIM}. @section Xtensa Architecture -Xtensa processors are based on a modular, highly flexible 32-bit RISC architecture -that can easily scale from a tiny, cache-less controller or task engine to a high-performance -SIMD/VLIW DSP provided by Cadence. -@url{https://www.cadence.com/en_US/home/tools/ip/tensilica-ip/tensilica-xtensa-controllers-and-extensible-processors.html}. -OpenOCD supports generic Xtensa processors implementation which can be customized by -simply providing vendor-specific core configuration which controls every configurable +Xtensa is a highly-customizable, user-extensible microprocessor and DSP +architecture for complex embedded systems provided by Cadence Design +Systems, Inc. See the +@uref{https://www.cadence.com/en_US/home/tools/ip/tensilica-ip.html, Tensilica IP} +website for additional information and documentation. + +OpenOCD supports generic Xtensa processor implementations which can be customized by +providing a core-specific configuration file which describes every enabled Xtensa architecture option, e.g. number of address registers, exceptions, reduced -size instructions support, memory banks configuration etc. Also OpenOCD supports SMP -configurations for Xtensa processors with any number of cores and allows to configure -their debug signals interconnection (so-called "break/stall networks") which control how -debug signals are distributed among cores. Xtensa "break networks" are compatible with -ARM's Cross Trigger Interface (CTI). For debugging code on Xtensa chips OpenOCD -uses JTAG protocol. Currently OpenOCD implements several Epsressif Xtensa-based chips of +size instructions support, memory banks configuration etc. OpenOCD also supports SMP +configurations for Xtensa processors with any number of cores and allows configuring +their debug interconnect (termed "break/stall networks"), which control how debug +signals are distributed among cores. Xtensa "break networks" are compatible with +ARM's Cross Trigger Interface (CTI). OpenOCD implements both generic Xtensa targets +as well as several Espressif Xtensa-based chips from the @uref{https://www.espressif.com/en/products/socs, ESP32 family}. -@subsection General Xtensa Commands +OCD sessions for Xtensa processor and DSP targets are accessed via the Xtensa +Debug Module (XDM), which provides external connectivity either through a +traditional JTAG interface or an ARM DAP interface. If used, the DAP interface +can control Xtensa targets through JTAG or SWD probes. + +@subsection Xtensa Core Configuration + +Due to the high level of configurability in Xtensa cores, the Xtensa target +configuration comprises two categories: + +@enumerate +@item Base Xtensa support common to all core configurations, and +@item Core-specific support as configured for individual cores. +@end enumerate + +All common Xtensa support is built into the OpenOCD Xtensa target layer and +is enabled through a combination of TCL scripts: the target-specific +@file{target/xtensa.cfg} and a board-specific @file{board/xtensa-*.cfg}, +similar to other target architectures. + +Importantly, core-specific configuration information must be provided by +the user, and takes the form of an @file{xtensa-core-XXX.cfg} TCL script that +defines the core's configurable features through a series of Xtensa +configuration commands (detailed below). + +This core-specific @file{xtensa-core-XXX.cfg} file is typically either: + +@itemize @bullet +@item Located within the Xtensa core configuration build as +@file{src/config/xtensa-core-openocd.cfg}, or +@item Generated by running the command @code{xt-gdb --dump-oocd-config} +from the Xtensa processor tool-chain's command-line tools. +@end itemize + +NOTE: @file{xtensa-core-XXX.cfg} must match the target Xtensa hardware +connected to OpenOCD. + +Some example Xtensa configurations are bundled with OpenOCD for reference: +@itemize @bullet +@item Cadence Palladium VDebug emulation target. The user can combine their +@file{xtensa-core-XXX.cfg} with the provided +@file{board/xtensa-palladium-vdebug.cfg} to debug an emulated Xtensa RTL design. +@item NXP MIMXRT685-EVK evaluation kit. The relevant configuration files are +@file{board/xtensa-rt685-jlink.cfg} and @file{board/xtensa-core-nxp_rt600.cfg}. +Additional information is provided by +@uref{https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/i-mx-rt600-evaluation-kit:MIMXRT685-EVK, +NXP}. +@end itemize + +@subsection Xtensa Configuration Commands + +@deffn {Command} {xtensa xtdef} (@option{LX}|@option{NX}) +Configure the Xtensa target architecture. Currently, Xtensa support is limited +to LX6, LX7, and NX cores. +@end deffn + +@deffn {Command} {xtensa xtopt} option value +Configure Xtensa target options that are relevant to the debug subsystem. +@var{option} is one of: @option{arnum}, @option{windowed}, +@option{cpenable}, @option{exceptions}, @option{intnum}, @option{hipriints}, +@option{excmlevel}, @option{intlevels}, @option{debuglevel}, +@option{ibreaknum}, or @option{dbreaknum}. @var{value} is an integer with +the exact range determined by each particular option. + +NOTE: Some options are specific to Xtensa LX or Xtensa NX architecture, while +others may be common to both but have different valid ranges. +@end deffn + +@deffn {Command} {xtensa xtmem} (@option{iram}|@option{dram}|@option{sram}|@option{irom}|@option{drom}|@option{srom}) baseaddr bytes +Configure Xtensa target memory. Memory type determines access rights, +where RAMs are read/write while ROMs are read-only. @var{baseaddr} and +@var{bytes} are both integers, typically hexadecimal and decimal, respectively. +@end deffn + +@deffn {Command} {xtensa xtmem} (@option{icache}|@option{dcache}) linebytes cachebytes ways [writeback] +Configure Xtensa processor cache. All parameters are required except for +the optional @option{writeback} parameter; all are integers. +@end deffn + +@deffn {Command} {xtensa xtmpu} numfgseg minsegsz lockable execonly +Configure an Xtensa Memory Protection Unit (MPU). MPUs can restrict access +and/or control cacheability of specific address ranges, but are lighter-weight +than a full traditional MMU. All parameters are required; all are integers. +@end deffn + +@deffn {Command} {xtensa xtmmu} numirefillentries numdrefillentries +(Xtensa-LX only) Configure an Xtensa Memory Management Unit (MMU). Both +parameters are required; both are integers. +@end deffn + +@deffn {Command} {xtensa xtregs} numregs +Configure the total number of registers for the Xtensa core. Configuration +logic expects to subsequently process this number of @code{xtensa xtreg} +definitions. @var{numregs} is an integer. +@end deffn + +@deffn {Command} {xtensa xtregfmt} (@option{sparse}|@option{contiguous}) [general] +Configure the type of register map used by GDB to access the Xtensa core. +Generic Xtensa tools (e.g. xt-gdb) require @option{sparse} mapping (default) while +Espressif tools expect @option{contiguous} mapping. Contiguous mapping takes an +additional, optional integer parameter @option{numgregs}, which specifies the number +of general registers used in handling g/G packets. +@end deffn + +@deffn {Command} {xtensa xtreg} name offset +Configure an Xtensa core register. All core registers are 32 bits wide, +while TIE and user registers may have variable widths. @var{name} is a +character string identifier while @var{offset} is a hexadecimal integer. +@end deffn + +@subsection Xtensa Operation Commands + +@deffn {Command} {xtensa maskisr} (@option{on}|@option{off}) +(Xtensa-LX only) Mask or unmask Xtensa interrupts during instruction step. +When masked, an interrupt that occurs during a step operation is handled and +its ISR is executed, with the user's debug session returning after potentially +executing many instructions. When unmasked, a triggered interrupt will result +in execution progressing the requested number of instructions into the relevant +vector/ISR code. +@end deffn @deffn {Command} {xtensa set_permissive} (0|1) By default accessing memory beyond defined regions is forbidden. This commnd controls memory access address check. When set to (1), skips access controls and address range check before read/write memory. @end deffn -@deffn {Command} {xtensa maskisr} (on|off) -Selects whether interrupts will be disabled during stepping over single instruction. The default configuration is (off). -@end deffn - @deffn {Command} {xtensa smpbreak} [none|breakinout|runstall] | [BreakIn] [BreakOut] [RunStallIn] [DebugModeOut] Configures debug signals connection ("break network") for currently selected core. @itemize @bullet @@ -10985,6 +11103,13 @@ This feature is not well implemented and tested yet. @end itemize @end deffn +@deffn {Command} {xtensa exe} +Execute arbitrary instruction(s) provided as an ascii string. The string represents an integer +number of instruction bytes, thus its length must be even. +@end deffn + +@subsection Xtensa Performance Monitor Configuration + @deffn {Command} {xtensa perfmon_enable}