zcy
/
tinyriscv-openocd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'master' into from_upstream

riscv-compliance
Tim Newsome 2018-05-30 16:06:08 -07:00
parent ab7ab8a867 b50fa9a19d
commit b39b05ff77
16 changed files with 84 additions and 82 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
configure.ac
View File

@ -659,7 +659,7 @@ PROCESS_ADAPTERS([USB0_ADAPTERS], ["x$use_libusb0" = "xyes"], [libusb-0.1])
PROCESS_ADAPTERS([HIDAPI_ADAPTERS], ["x$use_hidapi" = "xyes"], [hidapi]) PROCESS_ADAPTERS([HIDAPI_ADAPTERS], ["x$use_hidapi" = "xyes"], [hidapi])
PROCESS_ADAPTERS([HIDAPI_USB1_ADAPTERS], ["x$use_hidapi" = "xyes" -a "x$use_libusb1" = "xyes"], [hidapi and libusb-1.x]) PROCESS_ADAPTERS([HIDAPI_USB1_ADAPTERS], ["x$use_hidapi" = "xyes" -a "x$use_libusb1" = "xyes"], [hidapi and libusb-1.x])
PROCESS_ADAPTERS([LIBFTDI_ADAPTERS], ["x$use_libftdi" = "xyes"], [libftdi]) PROCESS_ADAPTERS([LIBFTDI_ADAPTERS], ["x$use_libftdi" = "xyes"], [libftdi])
PROCESS_ADAPTERS([LIBJAYLINK_ADAPTERS], ["x$use_internal_libjaylink" = "xyes" -o "x$use_libjaylink" = "xyes"], [libjaylink-0.1]) PROCESS_ADAPTERS([LIBJAYLINK_ADAPTERS], ["x$use_internal_libjaylink" = "xyes" -o "x$use_libjaylink" = "xyes"], [libjaylink-0.2])
AS_IF([test "x$build_openjtag" = "xyes"], [ AS_IF([test "x$build_openjtag" = "xyes"], [
AS_IF([test "x$use_libusb1" != "xyes" -a "x$use_libusb0" != "xyes"], [ AS_IF([test "x$use_libusb1" != "xyes" -a "x$use_libusb0" != "xyes"], [

4
doc/manual/jtag/drivers/remote_bitbang.txt
View File

@ -28,7 +28,7 @@ An additional function, quit, is added to the remote_bitbang interface to
indicate there will be no more requests and the connection with the remote indicate there will be no more requests and the connection with the remote
driver should be closed. driver should be closed.
These five functions are encoded in ascii by assigning a single character to These five functions are encoded in ASCII by assigning a single character to
each possible request. The assignments are: each possible request. The assignments are:
B - Blink on B - Blink on
@ -48,6 +48,6 @@ each possible request. The assignments are:
t - Reset 1 0 t - Reset 1 0
u - Reset 1 1 u - Reset 1 1
The read response is encoded in ascii as either digit 0 or 1. The read response is encoded in ASCII as either digit 0 or 1.
*/ */

2
doc/manual/primer/autotools.txt
View File

@ -123,7 +123,7 @@ implement new checks.
The <code>make distcheck</code> command produces an archive of the The <code>make distcheck</code> command produces an archive of the
project deliverables (using <code>make dist</code>) and verifies its project deliverables (using <code>make dist</code>) and verifies its
integrity for distribution by attemptng to use the package in the same integrity for distribution by attempting to use the package in the same
manner as a user. manner as a user.
These checks includes the following steps: These checks includes the following steps:

2
doc/manual/primer/commands.txt
View File

@ -30,7 +30,7 @@ called (with the appropriate parameters), the @c CALL_COMMAND_HANDLER
macro to pass any e as parameters to the following helper function: macro to pass any e as parameters to the following helper function:
The subsequent blocks of code are a normal C function that can do The subsequent blocks of code are a normal C function that can do
anything, so only complex commands deserve should use comamnd helper anything, so only complex commands deserve should use command helper
functions. In this respect, this example uses one to demonstrate how -- functions. In this respect, this example uses one to demonstrate how --
not when -- they should be used. not when -- they should be used.

2
doc/manual/primer/docs.txt
View File

@ -19,7 +19,7 @@ OpenOCD presently produces several kinds of documentation:
- See @subpage primerlatex and @ref stylelatex. - See @subpage primerlatex and @ref stylelatex.
- The Manual: - The Manual:
- Focuses on developing the OpenOCD software. - Focuses on developing the OpenOCD software.
- Details the architecutre, driver interfaces, and processes. - Details the architecture, driver interfaces, and processes.
- Provides "full" coverage of C source code (work-in-progress). - Provides "full" coverage of C source code (work-in-progress).
- Written using Doxygen C language conventions (i.e. in comments). - Written using Doxygen C language conventions (i.e. in comments).
- Created with 'make doxygen'. - Created with 'make doxygen'.

26
doc/manual/primer/tcl.txt
View File

@ -125,7 +125,7 @@ There is some tricky things going on.
=============== ===============
First, there is a "for" loop - at level 0 First, there is a "for" loop - at level 0
{level 0 means: out side of a proc/function} {level 0 means: outside of a procedure/function}
This means it is evaluated when the file is parsed. This means it is evaluated when the file is parsed.
@ -151,9 +151,9 @@ The FOR command:
5) Goto Step 2. 5) Goto Step 2.
As show, each of these items are in {curly-braces}. This means they As show, each of these items are in {curly-braces}. This means they
are passed as they are - KEY-POINT: un evaluated to the FOR are passed as they are - KEY-POINT: unevaluated to the FOR
command. Think of it like escaping the backticks in Bash so that the command. Think of it like escaping the backticks in Bash so that the
"under-lying" command can evaluate the contents. In this case, the FOR "underlying" command can evaluate the contents. In this case, the FOR
COMMAND. COMMAND.
== END: SIDEBAR: About The FOR command == == END: SIDEBAR: About The FOR command ==
@ -167,9 +167,9 @@ Format is like "sprintf". Because of the [brackets], it becomes what
you think. But here's how: you think. But here's how:
First - the line is parsed - for {braces}. In this case, there are First - the line is parsed - for {braces}. In this case, there are
none. The, the parser looks for [brackets] and finds them. The, none. Then, the parser looks for [brackets] and finds them. The
parser then evaluates the contents of the [brackets], and replaces parser then evaluates the contents of the [brackets], and replaces
them. It is alot this bash statement. them. It is similar to this bash statement.
EXPORT vn=`date` EXPORT vn=`date`
@ -179,7 +179,7 @@ LINE 2 & 3
In line 1, we dynamically created a variable name. Here, we are In line 1, we dynamically created a variable name. Here, we are
assigning it a value. Lastly Line 3 we force the variable to be assigning it a value. Lastly Line 3 we force the variable to be
global, not "local" the the "for command body" global, not "local" within the "for command body"
=============== ===============
The PROCS The PROCS
@ -194,7 +194,7 @@ The (1) NAME of the function, a (2) LIST of parameters, and a (3) BODY
Again, this is at "level 0" so it is a global function. (Yes, TCL Again, this is at "level 0" so it is a global function. (Yes, TCL
supports local functions, you put them inside of a function} supports local functions, you put them inside of a function}
You'll see in some cases, I nest [brackets] alot and in others I'm You'll see in some cases, I nest [brackets] a lot and in others I'm
lazy or wanted it to be more clear... it is a matter of choice. lazy or wanted it to be more clear... it is a matter of choice.
=============== ===============
@ -224,7 +224,7 @@ All memory regions must have 2 things:
RWX - the access ability. RWX - the access ability.
WIDTH - the accessible width. WIDTH - the accessible width.
ie: Some regions of memory are not 'word' i.e.: Some regions of memory are not 'word'
accessible. accessible.
The function "address_info" - given an address should The function "address_info" - given an address should
@ -287,7 +287,7 @@ Notice this IF COMMAND - (not statement) is like this:
error [format string...] error [format string...]
} }
The "IF" command expects either 2 params, or 4 params. The "IF" command expects either 2 or 4 parameters.
=== Sidebar: About "commands" === === Sidebar: About "commands" ===
@ -317,7 +317,7 @@ You give CATCH 1 or 2 parameters.
The 2nd (optional) is where to put the error message. The 2nd (optional) is where to put the error message.
CATCH returns 0 on success, 1 for failure. CATCH returns 0 on success, 1 for failure.
The "![catch command]" is self explaintory. The "![catch command]" is self explanatory.
The 3rd parameter to IF must be exactly "else" or "elseif" [I lied The 3rd parameter to IF must be exactly "else" or "elseif" [I lied
@ -341,7 +341,7 @@ exists. {the function: "proc_exists" does this}
And - if it does - I call the function. And - if it does - I call the function.
In "C" it is alot like using: 'sprintf()' to construct a function name In "C" it is a lot like using: 'sprintf()' to construct a function name
string, then using "dlopen()" and "dlsym()" to look it up - and get a string, then using "dlopen()" and "dlsym()" to look it up - and get a
function pointer - and calling the function pointer. function pointer - and calling the function pointer.
@ -380,7 +380,7 @@ Some assumptions:
The "CHIP" file has defined some variables in a proper form. The "CHIP" file has defined some variables in a proper form.
ie: AT91C_BASE_US0 - for usart0, i.e.: AT91C_BASE_US0 - for usart0,
AT91C_BASE_US1 - for usart1 AT91C_BASE_US1 - for usart1
... And so on ... ... And so on ...
@ -394,7 +394,7 @@ looks like this:
In this case, I'm trying to figure out what USARTs exist. In this case, I'm trying to figure out what USARTs exist.
Step 1 - is to determine if the NAME has been defined. Step 1 - is to determine if the NAME has been defined.
ie: Does AT91C_BASE_USx - where X is some number exist? i.e.: Does AT91C_BASE_USx - where X is some number exist?
The "info exists VARNAME" tells you if the variable exists. Then - The "info exists VARNAME" tells you if the variable exists. Then -
inside the IF statement... There is another loop. This loop is the inside the IF statement... There is another loop. This loop is the

8
doc/manual/release.txt
View File

@ -36,7 +36,7 @@ several important advantages compared to using the source repository
were produced as part of creating the archive. were produced as part of creating the archive.
-# Because they have been formally released by the project, users -# Because they have been formally released by the project, users
don't need to try a random work-in-process revision. Releasing don't need to try a random work-in-process revision. Releasing
involves spending some time specifically on quality improvments, involves spending some time specifically on quality improvements,
including bugfixing source code and documentation. including bugfixing source code and documentation.
-# They provide developers with the flexibility needed to address -# They provide developers with the flexibility needed to address
larger issues, which sometimes involves temporary breakage. larger issues, which sometimes involves temporary breakage.
@ -149,7 +149,7 @@ specific git revisions:
0.3.0-rc1-dev-00015-gf37c9b8-dirty 0.3.0-rc1-dev-00015-gf37c9b8-dirty
indicates a development tree based on git revison f37c9b8 indicates a development tree based on git revision f37c9b8
(a truncated version of a SHA1 hash) with some non-git (a truncated version of a SHA1 hash) with some non-git
patches applied (the <em>dirty</em> tag). This information patches applied (the <em>dirty</em> tag). This information
can be useful when tracking down bugs. can be useful when tracking down bugs.
@ -385,7 +385,7 @@ git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}"
- Last updates for the release, including the release tag (you - Last updates for the release, including the release tag (you
will need to "git push --tags"). will need to "git push --tags").
- Updates opening the merge window - Updates opening the merge window
- At this point, it's OK for commiters to start pushing changes - At this point, it's OK for committers to start pushing changes
which have been held off until the next release. (Any bugfixes to which have been held off until the next release. (Any bugfixes to
this release will be against a bug-fix release branch starting from this release will be against a bug-fix release branch starting from
the commit you tagged as this release, not mainline.) the commit you tagged as this release, not mainline.)
@ -423,7 +423,7 @@ tools/release.sh --type=micro branch
Both of these variations make automatic commits and tags in your Both of these variations make automatic commits and tags in your
repository, so you should be sure to run it on a cloned copy before repository, so you should be sure to run it on a cloned copy before
proceding with a live release. proceeding with a live release.
@subsection releasescriptopts Release Script Options @subsection releasescriptopts Release Script Options

2
doc/manual/scripting.txt
View File

@ -43,7 +43,7 @@ Default implementation of procedures in tcl/procedures.tcl.
functions constitute the tcl api. flash_banks is such functions constitute the tcl api. flash_banks is such
a low level tcl proc. "flash banks" is an example of a low level tcl proc. "flash banks" is an example of
a command that has human readable output. The human a command that has human readable output. The human
readable output is expected to change inbetween versions readable output is expected to change in between versions
of OpenOCD. The output from flash_banks may not be of OpenOCD. The output from flash_banks may not be
in the preferred form for the client. The client then in the preferred form for the client. The client then
has two choices a) parse the output from flash_banks has two choices a) parse the output from flash_banks

36
doc/manual/server.txt
View File

@ -29,7 +29,7 @@ write new code and creates a support nightmare.
In many ways, people had talked about the need for some type of In many ways, people had talked about the need for some type of
high-level interface to OpenOCD, because they only had two choices: high-level interface to OpenOCD, because they only had two choices:
- the ability to script: via an external program the actions of OpenOCD. - the ability to script: via an external program the actions of OpenOCD.
- the ablity to write a complex internal commands: native 'commands' - the ability to write a complex internal commands: native 'commands'
inside of OpenOCD was complicated. inside of OpenOCD was complicated.
Fundamentally, the basic problem with both of those would be solved Fundamentally, the basic problem with both of those would be solved
@ -68,7 +68,7 @@ interfaces well with TCL.
From there, the developers wanted to create an external front-end that From there, the developers wanted to create an external front-end that
would be @a very usable and that that @a any language could utilize, would be @a very usable and that that @a any language could utilize,
allowing simple front-ends to be (a) cross-platform (b) languag allowing simple front-ends to be (a) cross-platform (b) language
agnostic, and (c) easy to develop and use. agnostic, and (c) easy to develop and use.
Simple ASCII protocols are easy. For example, HTTP, FTP (control), and Simple ASCII protocols are easy. For example, HTTP, FTP (control), and
@ -76,7 +76,7 @@ SMTP are all text-based. All of these examples are widely and
well-known, and they do not require high-speed or high-volume. They well-known, and they do not require high-speed or high-volume. They
also support a high degree of interoperability with multiple systems. also support a high degree of interoperability with multiple systems.
They are not human-centric protocols; more correctly, they are rigid, They are not human-centric protocols; more correctly, they are rigid,
terse, simple ASCII protocols that are emensely parsable by a script. terse, simple ASCII protocols that are easily parsable by a script.
Thus, the TCL server -- a 'machine' type socket interface -- was added Thus, the TCL server -- a 'machine' type socket interface -- was added
with the hope was it would output simple "name-value" pair type with the hope was it would output simple "name-value" pair type
@ -95,25 +95,25 @@ and do things with it!
A lot has been said about various "widigit-foo-gui-library is so A lot has been said about various "widigit-foo-gui-library is so
wonderful". Please refer back to the domino and spider web problem of wonderful". Please refer back to the domino and spider web problem of
dependencies. Sure, you may well know the WhatEver-GUI library, but dependencies. Sure, you may well know the WhatEver-GUI library, but
most others will not (including the next contributer to OpenOCD). most others will not (including the next contributor to OpenOCD).
How do we solve that problem? How do we solve that problem?
For example, Cygwin can be painful, Cygwin GUI packages want X11 For example, Cygwin can be painful, Cygwin GUI packages want X11
to be present, crossing the barrier between MinGW and Cygwin is to be present, crossing the barrier between MinGW and Cygwin is
painful, let alone getting the GUI front end to work on MacOS, and painful, let alone getting the GUI front end to work on MacOS, and
Linux, yuck yuck yuck. Painful. very very painful. Linux, yuck yuck yuck. Painful, very very painful.
What works easier and is less work is what is already present in every What works easier and is less work is what is already present in every
platform? The answer: A web browser. In other words, OpenOCD could platform? The answer: A web browser. In other words, OpenOCD could
serve out embedded web pages via "localhost" to your browser. serve out embedded web pages via "localhost" to your browser.
Long before OpenOCD had a TCL command line, Zylin AS built their ZY1000 Long before OpenOCD had a TCL command line, Zylin AS built their ZY1000
devince with a built-in HTTP server. Later, they were willing to both device with a built-in HTTP server. Later, they were willing to both
contribute and integrate most of that work into the main tree. contribute and integrate most of that work into the main tree.
@subsection serverdocsother Other Options Considered @subsection serverdocsother Other Options Considered
What if a web browser is not acceptable ie: You want to write your own What if a web browser is not acceptable i.e.: You want to write your own
front gadget in Eclipse, or KDevelop, or PerlTK, Ruby, or what ever front gadget in Eclipse, or KDevelop, or PerlTK, Ruby, or what ever
the latest and greatest Script De Jour is. the latest and greatest Script De Jour is.
@ -134,7 +134,7 @@ taking over OpenOCD. His concern is and was: how do you debug
something written in 2 different languages? A "SWIG" front-end is something written in 2 different languages? A "SWIG" front-end is
unlikely to help that situation. unlikely to help that situation.
@subsection serverdoccombined Combined: Socket & WebServer Benifits @subsection serverdoccombined Combined: Socket & WebServer Benefits
Seriously think about this question: What script language (or compiled Seriously think about this question: What script language (or compiled
language) today cannot talk directly to a socket? Every thing in the language) today cannot talk directly to a socket? Every thing in the
@ -146,23 +146,23 @@ and serve it out via the embedded web server, could it - or something
like it talk to the built in TCL server? Yes, absolutely! We are on to like it talk to the built in TCL server? Yes, absolutely! We are on to
something here. something here.
@subsection serverdocplatforms Platform Permuntations @subsection serverdocplatforms Platform Permutations
Look at some permutations where OpenOCD can run; these "just work" if Look at some permutations where OpenOCD can run; these "just work" if
the Socket Approach is used. the Socket Approach is used.
- Linux/Cygwin/MinGw/MacOSx/FreeBSD development Host Locally - Linux/Cygwin/MinGW/MacOSX/FreeBSD development Host Locally
- OpenOCD with some dongle on that host - OpenOCD with some dongle on that host
- Linux/Cygwin/MingW/MacOS/FreeBSD development host - Linux/Cygwin/MinGW/MacOS/FreeBSD development host
- DONGLE: tcpip based ARM-Linux perhaps at91rm9200 or ep93xx.c, running openocd. - DONGLE: TCP/IP based ARM-Linux perhaps at91rm9200 or ep93xx.c, running openocd.
- Windows cygwin/X desktop environment. - Windows Cygwin/X desktop environment.
- Linux development host (via remote X11) - Linux development host (via remote X11)
- Dongle: "eb93xx.c" based linux board - Dongle: "eb93xx.c" based Linux board
@subsection serverdocfuture Development Scale Out @subsection serverdocfuture Development Scale Out
@ -214,8 +214,8 @@ love or attention. Perhaps it will after you read and understand this.
One reason might be, this adds one more host side requirement to make One reason might be, this adds one more host side requirement to make
use of the feature. In other words, one could write a Python/TK use of the feature. In other words, one could write a Python/TK
front-end, but it is only useable if you have Python/TK installed. front-end, but it is only useable if you have Python/TK installed.
Maybe this can be done via Ecllipse, but not all developers use Ecplise. Maybe this can be done via Eclipse, but not all developers use Eclipse.
Many devlopers use Emacs (possibly with GUD mode) or vim and will not Many developers use Emacs (possibly with GUD mode) or vim and will not
accept such an interface. The next developer reading this might be accept such an interface. The next developer reading this might be
using Insight (GDB-TK) - and somebody else - DDD.. using Insight (GDB-TK) - and somebody else - DDD..
@ -260,7 +260,7 @@ OS) is another example.
One could create a simple: <b>Click here to display memory</b> or maybe One could create a simple: <b>Click here to display memory</b> or maybe
<b>click here to display the UART REGISTER BLOCK</b>; click again and see <b>click here to display the UART REGISTER BLOCK</b>; click again and see
each register explained in exquisit detail. each register explained in exquisite detail.
For an STM32, one could create a simple HTML page, with simple For an STM32, one could create a simple HTML page, with simple
substitution text that the simple web server use to substitute the substitution text that the simple web server use to substitute the
@ -269,7 +269,7 @@ memory. We end up with an HTML page that could list the contents of
every peripheral register on the target platform. every peripheral register on the target platform.
That also is transportable, regardless of the OpenOCD host That also is transportable, regardless of the OpenOCD host
platform: Linux/X86, Linux/ARM, FreeBSD, Cygwin, MingW, or MacOSX. platform: Linux/X86, Linux/ARM, FreeBSD, Cygwin, MinGW, or MacOSX.
You could even port OpenOCD to an Android system and use it as a You could even port OpenOCD to an Android system and use it as a
bit-banging JTAG Adapter serving web pages. bit-banging JTAG Adapter serving web pages.

8
doc/manual/style.txt
View File

@ -112,7 +112,7 @@ pthreads require modest and predictable stack usage.
@section stylefunc Functions @section stylefunc Functions
- static inline functions should be prefered over macros: - static inline functions should be preferred over macros:
@code @code
/** do NOT define macro-like functions like this... */ /** do NOT define macro-like functions like this... */
#define CUBE(x) ((x) * (x) * (x)) #define CUBE(x) ((x) * (x) * (x))
@ -201,7 +201,7 @@ The following guidelines apply to all Doxygen comment blocks:
-# @c struct_name::member_name should be used to reference structure -# @c struct_name::member_name should be used to reference structure
fields in the documentation (e.g. @c flash_driver::name). fields in the documentation (e.g. @c flash_driver::name).
-# URLS get converted to markup automatically, without any extra effort. -# URLS get converted to markup automatically, without any extra effort.
-# new pages can be linked into the heirarchy by using the @c \@subpage -# new pages can be linked into the hierarchy by using the @c \@subpage
command somewhere the page(s) under which they should be linked: command somewhere the page(s) under which they should be linked:
-# use @c \@ref in other contexts to create links to pages and sections. -# use @c \@ref in other contexts to create links to pages and sections.
-# Use good Doxygen mark-up: -# Use good Doxygen mark-up:
@ -233,7 +233,7 @@ documentation as part of standalone text files:
- Doxygen creates such pages for files automatically, but no content - Doxygen creates such pages for files automatically, but no content
will appear on them for those that only contain manual pages. will appear on them for those that only contain manual pages.
- The \@file block should provide useful meta-documentation to assist - The \@file block should provide useful meta-documentation to assist
techincal writers; typically, a list of the pages that it contains. technical writers; typically, a list of the pages that it contains.
- For example, the @ref styleguide exists in @c doc/manual/style.txt, - For example, the @ref styleguide exists in @c doc/manual/style.txt,
which contains a reference back to itself. which contains a reference back to itself.
-# The \@file and \@page commands should begin on the same line as -# The \@file and \@page commands should begin on the same line as
@ -261,7 +261,7 @@ The User's Guide is there to provide two basic kinds of information. It
is a guide for how and why to use each feature or mechanism of OpenOCD. is a guide for how and why to use each feature or mechanism of OpenOCD.
It is also the reference manual for all commands and options involved It is also the reference manual for all commands and options involved
in using them, including interface, flash, target, and other drivers. in using them, including interface, flash, target, and other drivers.
At this time, it is the only user-targetted documentation; everything At this time, it is the only documentation for end users; everything
else is addressing OpenOCD developers. else is addressing OpenOCD developers.
There are two key audiences for the User's Guide, both developer based. There are two key audiences for the User's Guide, both developer based.

50
doc/manual/target/mips.txt
View File

@ -46,14 +46,14 @@ This value is defined only when a processor access is pending.
Processor will do the action for us : it can for example read internal state (register values), Processor will do the action for us : it can for example read internal state (register values),
and send us back the information via EJTAG memory (dmseg), or it can take some data from dmseg and write it into the registers or RAM. and send us back the information via EJTAG memory (dmseg), or it can take some data from dmseg and write it into the registers or RAM.
Every time when it sees address (i.e. when this address is the part of the opcode it is executing, wether it is instruction or data fetch) Every time when it sees address (i.e. when this address is the part of the opcode it is executing, whether it is instruction or data fetch)
that falls into dmseg, processor stalls. That acutally meand that CPU stops it's pipeline and it is waitning for dongle to take some action. that falls into dmseg, processor stalls. That actually means that CPU stops it's pipeline and it is waiting for dongle to take some action.
CPU is now either waiting for dongle to take some data from dmseg (if we requested for CPU do give us internal state, for example), CPU is now either waiting for dongle to take some data from dmseg (if we requested for CPU do give us internal state, for example),
or it will wait for some data from dongle (if it needs following instruction because it did previous, or if the operand address of the currently executed opcode or it will wait for some data from dongle (if it needs following instruction because it did previous, or if the operand address of the currently executed opcode
falls somewhere (anywhere) in dmseg (0xff..ff20000 - 0xff..ff2fffff)). falls somewhere (anywhere) in dmseg (0xff..ff20000 - 0xff..ff2fffff)).
Bit PNnW describes character of CPU access to EJTAG memory (the memry where dongle puts/takes data) - CPU can either READ for it (PNnW == 0) or Bit PNnW describes character of CPU access to EJTAG memory (the memory where dongle puts/takes data) - CPU can either READ for it (PNnW == 0) or
WRITE to it (PNnW == 1). WRITE to it (PNnW == 1).
By reading PNnW bit OpenOCD will know if it has to send (PNnW == 0) or to take (PNnW == 1) data (from dmseg, via dongle). By reading PNnW bit OpenOCD will know if it has to send (PNnW == 0) or to take (PNnW == 1) data (from dmseg, via dongle).
@ -79,7 +79,7 @@ OpenOCD can figure out which action has to be taken by reading PrAcc bit.
Once action from dongle has been done, i.e. after the data is taken/put, OpenOCD can signal to CPU to proceed with executing the instruction. Once action from dongle has been done, i.e. after the data is taken/put, OpenOCD can signal to CPU to proceed with executing the instruction.
This can be the next instruction (if previous was finished before pending), or the same instruction - if for example CPU was waiting on dongle This can be the next instruction (if previous was finished before pending), or the same instruction - if for example CPU was waiting on dongle
to give it an operand, because it saw in the instruction opcode that operand address is somewhere in dmseg. That prowoked the CPU to stall (it tried operand fetch to dmseg and stopped), to give it an operand, because it saw in the instruction opcode that operand address is somewhere in dmseg. That provoked the CPU to stall (it tried operand fetch to dmseg and stopped),
and PNnW bit is 0 (CPU does read from dmseg), and PrAcc is 1 (CPU is pending on dmseg access). and PNnW bit is 0 (CPU does read from dmseg), and PrAcc is 1 (CPU is pending on dmseg access).
@subsection spracc SPrAcc @subsection spracc SPrAcc
@ -155,16 +155,16 @@ static const uint32_t code[] = {
We have to pass this code to CPU via dongle via dmseg. We have to pass this code to CPU via dongle via dmseg.
After debug exception CPU will find itself stalling at the begining of the dmseg. It waits for the first instruction from dongle. After debug exception CPU will find itself stalling at the beginning of the dmseg. It waits for the first instruction from dongle.
This is MIPS32_MTC0(15,31,0), so CPU saves C0 and continues to addr 0xFF20 0001, which falls also to dmseg, so it stalls. This is MIPS32_MTC0(15,31,0), so CPU saves C0 and continues to addr 0xFF20 0001, which falls also to dmseg, so it stalls.
Dongle proceeds giving to CPU one by one instruction in this manner. Dongle proceeds giving to CPU one by one instruction in this manner.
However, things are not so simple. If you take a look at the program, you will see that some instructions take operands. If it has to take However, things are not so simple. If you take a look at the program, you will see that some instructions take operands. If it has to take
operand from the address in dmseg, CPU will stall witing for the dongle to do the action of passing the operand and signal this by putting PrAcc to 0. operand from the address in dmseg, CPU will stall waiting for the dongle to do the action of passing the operand and signal this by putting PrAcc to 0.
If this operand is somewhere in RAM, CPU will not stall (it stalls only on dmseg), but it will just take it and proceed to nex instruction. But since PC for next instruction If this operand is somewhere in RAM, CPU will not stall (it stalls only on dmseg), but it will just take it and proceed to next instruction. But since PC for next instruction
points to dmseg, it will stall, so that dongle can pass next instruction. points to dmseg, it will stall, so that dongle can pass next instruction.
Some instuctions are jumps (if these are jumps in dmseg addr, CPU will jump and then stall. If this is jump to some address in RAM, CPU will jump and just proceed - Some instructions are jumps (if these are jumps in dmseg addr, CPU will jump and then stall. If this is jump to some address in RAM, CPU will jump and just proceed -
will not stall on addresses in RAM). will not stall on addresses in RAM).
To have information about CPU is currently (does it stalls wanting on operand or it jumped somewhere waiting for next instruction), To have information about CPU is currently (does it stalls wanting on operand or it jumped somewhere waiting for next instruction),
@ -213,10 +213,10 @@ else
@endcode @endcode
i.e. if CPU is stalling on addresses in dmseg that are reserved for input parameters, we can conclude that it actually tried to take (read) i.e. if CPU is stalling on addresses in dmseg that are reserved for input parameters, we can conclude that it actually tried to take (read)
parametar from there, and saw that address of param falls in dmseg, so it stopped. Obviously, now dongle have to give to it operand. parameter from there, and saw that address of parameter falls in dmseg, so it stopped. Obviously, now dongle have to give to it operand.
Similarly, mips32_pracc_exec_write() describes CPU writes into EJTAG memory (dmseg). Similarly, mips32_pracc_exec_write() describes CPU writes into EJTAG memory (dmseg).
Obvioulsy, code is RO, and CPU can change only parameters : Obviously, code is RO, and CPU can change only parameters :
@code @code
mips_ejtag_set_instr(ctx->ejtag_info, EJTAG_INST_DATA); mips_ejtag_set_instr(ctx->ejtag_info, EJTAG_INST_DATA);
@ -331,10 +331,10 @@ uint32_t handler_code[] = {
}; };
@endcode @endcode
In the begining and the end of the handler we have fuction prologue (save the regs that will be clobbered) and epilogue (restore regs), In the beginning and the end of the handler we have function prologue (save the regs that will be clobbered) and epilogue (restore regs),
and in the very end, after all the xfer have been done, we do jump to the MIPS32_PRACC_TEXT address, i.e. Debug Exception Vector location. and in the very end, after all the xfer have been done, we do jump to the MIPS32_PRACC_TEXT address, i.e. Debug Exception Vector location.
We will use this fact (that we came back to MIPS32_PRACC_TEXT) to verify later if all the handler is executed (because when in RAM, We will use this fact (that we came back to MIPS32_PRACC_TEXT) to verify later if all the handler is executed (because when in RAM,
processor do not stall - it executes all instructions untill one of them do not demand access to dmseg (if one of it's opernads is there)). processor do not stall - it executes all instructions until one of them do not demand access to dmseg (if one of it's operands is there)).
This handler is put into the RAM and executed from there, and not instruction by instruction, like in previous simple write This handler is put into the RAM and executed from there, and not instruction by instruction, like in previous simple write
(mips_m4k_write_memory()) and read (mips_m4k_read_memory()) functions. (mips_m4k_write_memory()) and read (mips_m4k_read_memory()) functions.
@ -347,12 +347,12 @@ MIPS32_LW(9,0,8) /* start addr in t1 */
and there it will stall - because it will see that one of the operands have to be fetched from dmseg (EJTAG memory, in this case FASTDATA memory segment). and there it will stall - because it will see that one of the operands have to be fetched from dmseg (EJTAG memory, in this case FASTDATA memory segment).
This handler is loaded in the RAM, ath the reserved location "work_area". This work_area is configured in OpenOCD configuration script and should be selected This handler is loaded in the RAM, at the reserved location "work_area". This work_area is configured in OpenOCD configuration script and should be selected
in that way that it is not clobbered (overwritten) by data we want to write-in using FASTDATA. in that way that it is not clobbered (overwritten) by data we want to write-in using FASTDATA.
What is executed instruction by instruction which is passed by dongle (via EJATG memory) is small jump code, which jumps at the handler in RAM. What is executed instruction by instruction which is passed by dongle (via EJATG memory) is small jump code, which jumps at the handler in RAM.
CPU stalls on dmseg when receiving these jmp_code instructions, but once it jumps in RAM, CPU do not stall anymore and executes bunch of handler instructions. CPU stalls on dmseg when receiving these jmp_code instructions, but once it jumps in RAM, CPU do not stall anymore and executes bunch of handler instructions.
Untill it comes to the first instruction which has an operand in FASTDATA area. There it stalls and waits on action from probe. Until it comes to the first instruction which has an operand in FASTDATA area. There it stalls and waits on action from probe.
It happens actually when CPU comes to this loop : It happens actually when CPU comes to this loop :
@code @code
@ -393,15 +393,15 @@ for (i = 0; i < count; i++)
} }
@endcode @endcode
Each time when OpenOCD fills data to CPU (via dongle, via dmseg), CPU takes it and proceeds in executing the endler. However, since handler is in a assembly loop, Each time when OpenOCD fills data to CPU (via dongle, via dmseg), CPU takes it and proceeds in executing the handler. However, since handler is in a assembly loop,
CPU comes to next instruction which also fetches data from FASTDATA area. So it stalls. CPU comes to next instruction which also fetches data from FASTDATA area. So it stalls.
Then OpenOCD fills the data again, from it's (OpenOCD's) loop. And this game continues untill all the data has been filled. Then OpenOCD fills the data again, from it's (OpenOCD's) loop. And this game continues untill all the data has been filled.
After the last data has beend given to CPU it sees that it reached the end address, so it proceeds with next instruction. However, rhis instruction do not point into dmseg, so After the last data has been given to CPU it sees that it reached the end address, so it proceeds with next instruction. However, this instruction do not point into dmseg, so
CPU executes bunch of handler instructions (all prologue) and in the end jumps to MIPS32_PRACC_TEXT address. CPU executes bunch of handler instructions (all prologue) and in the end jumps to MIPS32_PRACC_TEXT address.
On it's side, OpenOCD checks in CPU has jumped back to MIPS32_PRACC_TEXT, which is the confirmation that it correclty executed all the rest of the handler in RAM, On it's side, OpenOCD checks in CPU has jumped back to MIPS32_PRACC_TEXT, which is the confirmation that it correctly executed all the rest of the handler in RAM,
and that is not stuck somewhere in the RAM, or stalling on some acces in dmseg - that would be an error : and that is not stuck somewhere in the RAM, or stalling on some access in dmseg - that would be an error :
@code @code
address = 0; address = 0;
@ -462,7 +462,7 @@ Download flow (probe -> target block transfer) :
Note: A failure may have a recoverable (and even expected) cause like slow target execution of the load loop. Other failures may be due to unexpected more troublesome causes like an exception while in debug mode or a target hang on a bad target memory access. Note: A failure may have a recoverable (and even expected) cause like slow target execution of the load loop. Other failures may be due to unexpected more troublesome causes like an exception while in debug mode or a target hang on a bad target memory access.
Shifted out SPrAcc bit inform us that there was CPU access pendingand that it can be complete. Shifted out SPrAcc bit inform us that there was CPU access pending and that it can be complete.
Basically, we should do following procedure : Basically, we should do following procedure :
@ -497,7 +497,7 @@ by checking SPrAcc that we shifted out.
If some FASTDATA write fails, OpenOCD will continue with it's loop (on the host side), but CPU will rest pending (on the target side) If some FASTDATA write fails, OpenOCD will continue with it's loop (on the host side), but CPU will rest pending (on the target side)
waiting for correct FASTDATA write. waiting for correct FASTDATA write.
Since OpenOCD goes ahead, it will eventually finish it's loop, and proceede to check if CPU took all the data. But since CPU did not took all the data, Since OpenOCD goes ahead, it will eventually finish it's loop, and proceed to check if CPU took all the data. But since CPU did not took all the data,
it is still turns in handler's loop in RAM, stalling on Fastdata area so this check : it is still turns in handler's loop in RAM, stalling on Fastdata area so this check :
@code @code
@ -513,24 +513,24 @@ if (address != MIPS32_PRACC_TEXT)
fails, and that gives us enough information of the failure. fails, and that gives us enough information of the failure.
In this case, we can lower the JTAG frquency and try again, bacuse most probable reason of this failure is that we tried FASTDATA upload before CPU arrived to rise PrAcc (i.e. before it was pending on access). In this case, we can lower the JTAG frequency and try again, because most probable reason of this failure is that we tried FASTDATA upload before CPU arrived to rise PrAcc (i.e. before it was pending on access).
However, the reasons for failure might be numerous : reset, exceptions which can occur in debug mode, bus hangs, etc. However, the reasons for failure might be numerous : reset, exceptions which can occur in debug mode, bus hangs, etc.
If lowering the JTAG freq does not work either, we can fall back to more robust solution with patch posted below. If lowering the JTAG freq does not work either, we can fall back to more robust solution with patch posted below.
To summarize, FASTDATA communication goes as following : To summarize, FASTDATA communication goes as following :
-# CPU jumps to Debug Exception Vector Location 0xFF200200 in dmseg and it stalls, pending and waiting for EJTAG to give it first debug instruction and signall it by putting PrAcc to "0" -# CPU jumps to Debug Exception Vector Location 0xFF200200 in dmseg and it stalls, pending and waiting for EJTAG to give it first debug instruction and signal it by putting PrAcc to "0"
-# When PrAcc goes to "0" CPU execute one opcode sent by EJTAG via DATA reg. Then it pends on next access, waiting for PrAcc to be put to "0" again -# When PrAcc goes to "0" CPU execute one opcode sent by EJTAG via DATA reg. Then it pends on next access, waiting for PrAcc to be put to "0" again
-# Following this game, OpenOCD first loads handler code in RAM, and then sends the jmp_code - instruction by instruction via DATA reg, which redirects CPU to handler previously set up in RAM -# Following this game, OpenOCD first loads handler code in RAM, and then sends the jmp_code - instruction by instruction via DATA reg, which redirects CPU to handler previously set up in RAM
-# Once in RAM CPU does not pend on any instruction, but it executes all handler instructions untill first "fetch" to Fastdata area - then it stops and pends. -# Once in RAM CPU does not pend on any instruction, but it executes all handler instructions until first "fetch" to Fastdata area - then it stops and pends.
-# So - when it comes to any instruction (opcode) in this handler in RAM which reads (or writes) to Fastdata area (0xF..F20.0000 to 0xF..F20.000F), CPU stops (i.e. stalls access). -# So - when it comes to any instruction (opcode) in this handler in RAM which reads (or writes) to Fastdata area (0xF..F20.0000 to 0xF..F20.000F), CPU stops (i.e. stalls access).
I.e. it stops on this lw opcode and waits to FASTDATA TAP command from the probe. I.e. it stops on this lw opcode and waits to FASTDATA TAP command from the probe.
-# CPU continues only if OpenOCD shifted in SPrAcc "0" (and if the PrAcc was "1"). It shifts-out "1" to tell us that it was OK (processor was stalled, so it can complete the access), -# CPU continues only if OpenOCD shifted in SPrAcc "0" (and if the PrAcc was "1"). It shifts-out "1" to tell us that it was OK (processor was stalled, so it can complete the access),
and that it continued execution of the handler in RAM. and that it continued execution of the handler in RAM.
-# If PrAcc was not "1" CPU will not continue (go to next instruction), but will shift-out "0" and keep stalling on the same instruction of my handler in RAM. -# If PrAcc was not "1" CPU will not continue (go to next instruction), but will shift-out "0" and keep stalling on the same instruction of my handler in RAM.
-# When Fastdata loop is finished, CPU executes all following hadler instructions in RAM (prologue). -# When Fastdata loop is finished, CPU executes all following handler instructions in RAM (prologue).
-# In the end of my handler in RAM, I jumps back to begining of Debug Exception Vector Location 0xFF200200 in dmseg. -# In the end of my handler in RAM, I jumps back to beginning of Debug Exception Vector Location 0xFF200200 in dmseg.
-# When it jumps back to 0xFF200200 in dmseg processor stops and pends, waiting for OpenOCD to send it instruction via DATA reg and signal it by putting PrAcc to "0". -# When it jumps back to 0xFF200200 in dmseg processor stops and pends, waiting for OpenOCD to send it instruction via DATA reg and signal it by putting PrAcc to "0".
*/ */

2
doc/manual/target/notarm.txt
View File

@ -59,7 +59,7 @@ of the total OpenOCD system.
@section targetnotarmppc PowerPC @section targetnotarmppc PowerPC
there exists open source implementations of powerpc there exists open source implementations of PowerPC
target manipulation, but there hasn't been a lot target manipulation, but there hasn't been a lot
of activity in the mailing list. of activity in the mailing list.

10
src/flash/nor/kinetis.c
View File

@ -937,7 +937,7 @@ static int kinetis_create_missing_banks(struct kinetis_chip *k_chip)
unsigned num_blocks; unsigned num_blocks;
struct kinetis_flash_bank *k_bank; struct kinetis_flash_bank *k_bank;
struct flash_bank *bank; struct flash_bank *bank;
char base_name[80], name[80], num[4]; char base_name[69], name[80], num[4];
char *class, *p; char *class, *p;
num_blocks = k_chip->num_pflash_blocks + k_chip->num_nvm_blocks; num_blocks = k_chip->num_pflash_blocks + k_chip->num_nvm_blocks;
@ -948,7 +948,8 @@ static int kinetis_create_missing_banks(struct kinetis_chip *k_chip)
bank = k_chip->banks[0].bank; bank = k_chip->banks[0].bank;
if (bank && bank->name) { if (bank && bank->name) {
strncpy(base_name, bank->name, sizeof(base_name)); strncpy(base_name, bank->name, sizeof(base_name) - 1);
base_name[sizeof(base_name) - 1] = '\0';
p = strstr(base_name, ".pflash"); p = strstr(base_name, ".pflash");
if (p) { if (p) {
*p = '\0'; *p = '\0';
@ -960,7 +961,8 @@ static int kinetis_create_missing_banks(struct kinetis_chip *k_chip)
} }
} }
} else { } else {
strncpy(base_name, target_name(k_chip->target), sizeof(base_name)); strncpy(base_name, target_name(k_chip->target), sizeof(base_name) - 1);
base_name[sizeof(base_name) - 1] = '\0';
p = strstr(base_name, ".cpu"); p = strstr(base_name, ".cpu");
if (p) if (p)
*p = '\0'; *p = '\0';
@ -2012,7 +2014,7 @@ static int kinetis_probe_chip(struct kinetis_chip *k_chip)
unsigned cpu_mhz = 120; unsigned cpu_mhz = 120;
unsigned idx; unsigned idx;
bool use_nvm_marking = false; bool use_nvm_marking = false;
char flash_marking[11], nvm_marking[2]; char flash_marking[12], nvm_marking[2];
char name[40]; char name[40];
k_chip->probed = false; k_chip->probed = false;

4
src/jtag/drivers/kitprog.c
View File

@ -888,13 +888,11 @@ COMMAND_HANDLER(kitprog_handle_acquire_psoc_command)
COMMAND_HANDLER(kitprog_handle_serial_command) COMMAND_HANDLER(kitprog_handle_serial_command)
{ {
if (CMD_ARGC == 1) { if (CMD_ARGC == 1) {
size_t len = strlen(CMD_ARGV[0]); kitprog_serial = strdup(CMD_ARGV[0]);
kitprog_serial = calloc(len + 1, sizeof(char));
if (kitprog_serial == NULL) { if (kitprog_serial == NULL) {
LOG_ERROR("Failed to allocate memory for the serial number"); LOG_ERROR("Failed to allocate memory for the serial number");
return ERROR_FAIL; return ERROR_FAIL;
} }
strncpy(kitprog_serial, CMD_ARGV[0], len + 1);
} else { } else {
LOG_ERROR("expected exactly one argument to kitprog_serial <serial-number>"); LOG_ERROR("expected exactly one argument to kitprog_serial <serial-number>");
return ERROR_FAIL; return ERROR_FAIL;

2
src/target/arm_adi_v5.c
View File

@ -152,6 +152,8 @@ static uint32_t mem_ap_get_tar_increment(struct adiv5_ap *ap)
return 2; return 2;
case CSW_32BIT: case CSW_32BIT:
return 4; return 4;
default:
return 0;
} }
case CSW_ADDRINC_PACKED: case CSW_ADDRINC_PACKED:
return 4; return 4;

6
src/target/arm_disassembler.c
View File

@ -1549,7 +1549,7 @@ static int evaluate_misc_instr(uint32_t opcode,
} }
/* SMLAW < y> */ /* SMLAW < y> */
if (((opcode & 0x00600000) == 0x00100000) && (x == 0)) { if (((opcode & 0x00600000) == 0x00200000) && (x == 0)) {
uint8_t Rd, Rm, Rs, Rn; uint8_t Rd, Rm, Rs, Rn;
instruction->type = ARM_SMLAWy; instruction->type = ARM_SMLAWy;
Rd = (opcode & 0xf0000) >> 16; Rd = (opcode & 0xf0000) >> 16;
@ -1571,7 +1571,7 @@ static int evaluate_misc_instr(uint32_t opcode,
} }
/* SMUL < x><y> */ /* SMUL < x><y> */
if ((opcode & 0x00600000) == 0x00300000) { if ((opcode & 0x00600000) == 0x00600000) {
uint8_t Rd, Rm, Rs; uint8_t Rd, Rm, Rs;
instruction->type = ARM_SMULxy; instruction->type = ARM_SMULxy;
Rd = (opcode & 0xf0000) >> 16; Rd = (opcode & 0xf0000) >> 16;
@ -1592,7 +1592,7 @@ static int evaluate_misc_instr(uint32_t opcode,
} }
/* SMULW < y> */ /* SMULW < y> */
if (((opcode & 0x00600000) == 0x00100000) && (x == 1)) { if (((opcode & 0x00600000) == 0x00200000) && (x == 1)) {
uint8_t Rd, Rm, Rs; uint8_t Rd, Rm, Rs;
instruction->type = ARM_SMULWy; instruction->type = ARM_SMULWy;
Rd = (opcode & 0xf0000) >> 16; Rd = (opcode & 0xf0000) >> 16;