X-Git-Url: https://review.openocd.org/gitweb?p=openocd.git;a=blobdiff_plain;f=doc%2Fopenocd.texi;h=0b50c65b817767730d5dbbc3190dd2832e4eeed8;hp=e51de4de9108a01607e48faa8b6f5211c212eb00;hb=9c47dc9e8e49adff93cf8998638410259014513f;hpb=a87e699edf7d4d2f772bfa8f50535ad9f3086a56 diff --git a/doc/openocd.texi b/doc/openocd.texi index e51de4de91..0b50c65b81 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -2899,7 +2899,7 @@ This is a write-once setting. @end deffn @deffn {Interface Driver} {jlink} -Segger J-Link family of USB adapters. It currently supports only the JTAG transport. +Segger J-Link family of USB adapters. It currently supports JTAG and SWD transports. @quotation Compatibility Note Segger released many firmware versions for the many harware versions they @@ -3079,13 +3079,17 @@ This type of adapter does not expose some of the lower level api's that OpenOCD would normally use to access the target. Currently supported adapters include the ST STLINK and TI ICDI. +STLINK firmware version >= V2.J21.S4 recommended due to issues with earlier +versions of firmware where serial number is reset after first use. Suggest +using ST firmware update utility to upgrade STLINK firmware even if current +version reported is V2.J21.S4. @deffn {Config Command} {hla_device_desc} description Currently Not Supported. @end deffn @deffn {Config Command} {hla_serial} serial -Currently Not Supported. +Specifies the serial number of the adapter. @end deffn @deffn {Config Command} {hla_layout} (@option{stlink}|@option{icdi}) @@ -4165,10 +4169,9 @@ the given target with the given @var{name}; this is only relevant on boards which have more than one target. @end deffn -@section Target CPU Types and Variants +@section Target CPU Types @cindex target type @cindex CPU type -@cindex CPU variant Each target has a @dfn{CPU type}, as shown in the output of the @command{targets} command. You need to specify that type @@ -4181,20 +4184,13 @@ what core-specific commands may be available (@pxref{Architecture and Core Commands}), and more. -For some CPU types, OpenOCD also defines @dfn{variants} which -indicate differences that affect their handling. -For example, a particular implementation bug might need to be -worked around in some chip versions. - It's easy to see what target types are supported, since there's a command to list them. -However, there is currently no way to list what target variants -are supported (other than by reading the OpenOCD source code). @anchor{targettypes} @deffn Command {target types} Lists all supported target types. -At this writing, the supported CPU types and variants are: +At this writing, the supported CPU types are: @itemize @bullet @item @code{arm11} -- this is a generation of ARMv6 cores @@ -4214,17 +4210,9 @@ compact Thumb2 instruction set. (Support for this is still incomplete.) @item @code{fa526} -- resembles arm920 (w/o Thumb) @item @code{feroceon} -- resembles arm926 -@item @code{mips_m4k} -- a MIPS core. This supports one variant: +@item @code{mips_m4k} -- a MIPS core @item @code{xscale} -- this is actually an architecture, not a CPU type. It is based on the ARMv5 architecture. -There are several variants defined: -@itemize @minus -@item @code{ixp42x}, @code{ixp45x}, @code{ixp46x}, -@code{pxa27x} ... instruction register length is 7 bits -@item @code{pxa250}, @code{pxa255}, -@code{pxa26x} ... instruction register length is 5 bits -@item @code{pxa3xx} ... instruction register length is 11 bits -@end itemize @item @code{openrisc} -- this is an OpenRISC 1000 core. The current implementation supports three JTAG TAP cores: @itemize @minus @@ -4325,7 +4313,6 @@ and in other places the target needs to be identified. @item @var{configparams} ... all parameters accepted by @command{$target_name configure} are permitted. If the target is big-endian, set it here with @code{-endian big}. -If the variant matters, set it here with @code{-variant}. You @emph{must} set the @code{-chain-position @var{dotted.name}} here. @end itemize @@ -4339,7 +4326,7 @@ using the @command{$target_name cget} command. @emph{Warning:} changing some of these after setup is dangerous. For example, moving a target from one TAP to another; -and changing its endianness or variant. +and changing its endianness. @itemize @bullet @@ -4356,9 +4343,6 @@ Calling this twice with two different event names assigns two different handlers, but calling it twice with the same event name assigns only one handler. -@item @code{-variant} @var{name} -- specifies a variant of the target, -which OpenOCD needs to know about. - @item @code{-work-area-backup} (@option{0}|@option{1}) -- says whether the work area gets backed up; by default, @emph{it is not backed up.}