target: add generic Xtensa LX support
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 commit is contained in:
Ian Thompson
committed by
Antonio Borneo
Antonio Borneo
parent
be2e5c6c35
commit
ce5ca9f7ba
161
doc/openocd.texi
161
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} <ascii-encoded hexadecimal instruction bytes>
|
||||
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} <counter_id> <select> [mask] [kernelcnt] [tracelevel]
|
||||
Enable and start performance counter.
|
||||
@itemize @bullet
|
||||
@@ -11004,6 +11129,8 @@ whether to count.
|
||||
Dump performance counter value. If no argument specified, dumps all counters.
|
||||
@end deffn
|
||||
|
||||
@subsection Xtensa Trace Configuration
|
||||
|
||||
@deffn {Command} {xtensa tracestart} [pc <pcval>/[<maskbitcount>]] [after <n> [ins|words]]
|
||||
Set up and start a HW trace. Optionally set PC address range to trigger tracing stop when reached during program execution.
|
||||
This command also allows to specify the amount of data to capture after stop trigger activation.
|
||||
|
||||
Reference in New Issue
Block a user