auracaster/sw_openocd
3
0
Fork 0
forked from auracaster/openocd
Code Pull Requests Activity

Remove annoying end-of-line whitespace from doc/* files.

Browse Source 
git-svn-id: svn://svn.berlios.de/openocd/trunk@2744 b42882b7-edfa-0310-969c-e2dbd0fdcd60
This commit is contained in:
dbrownell
2009-09-21 18:52:45 +00:00
parent 71af49ca7f
commit b11d79110e
15 changed files with 131 additions and 131 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/manual/flash.txt
View File

@@ -7,7 +7,7 @@ FMI, etc.).
The Flash module provides the following APIs:
- @subpage flashcfi
- @subpage flashcfi
- @subpage flashnand
- @subpage flashtarget

2
doc/manual/jtag.txt
View File

@@ -32,7 +32,7 @@ asynchronous transactions.
- includes the Cable/TAP API (commands starting with @c tap_)
- @subpage jtagdriver
- @b private minidriver API
- @b private minidriver API
- declared in @c src/jtag/minidriver.h
- used @a only by the core and minidriver implementations:
- @c jtag_driver.c (in-tree OpenOCD drivers)

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

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

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

@@ -90,7 +90,7 @@ provide detailed documentation for each option.
To support out-of-tree building of the documentation, the @c Doxyfile.in
@c INPUT values will have all instances of the string @c "@srcdir@"
replaced with the current value of the make variable
<code>$(srcdir)</code>. The Makefile uses a rule to convert
<code>$(srcdir)</code>. The Makefile uses a rule to convert
@c Doxyfile.in into the @c Doxyfile used by <code>make doxygen</code>.
@section primerdoxyoocd OpenOCD Input Files
@@ -105,7 +105,7 @@ that can be found under the @c doc/manual directory in the project tree.
New files containing valid Doxygen markup that are placed in or under
that directory will be detected and included in The Manual automatically.
@section primerdoxyman Doxygen Reference Manual
@section primerdoxyman Doxygen Reference Manual
The full documentation for Doxygen can be referenced on-line at the project
home page: http://www.doxygen.org/index.html. In HTML versions of this

80
doc/manual/primer/jtag.txt
View File

@@ -1,14 +1,14 @@
/** @page primerjtag OpenOCD JTAG Primer
JTAG is unnecessarily confusing, because JTAG is often confused with
JTAG is unnecessarily confusing, because JTAG is often confused with
boundary scan, which is just one of its possible functions.
JTAG is simply a communication interface designed to allow communication
to functions contained on devices, for the designed purposes of
initialisation, programming, testing, debugging, and anything else you
JTAG is simply a communication interface designed to allow communication
to functions contained on devices, for the designed purposes of
initialisation, programming, testing, debugging, and anything else you
want to use it for (as a chip designer).
Think of JTAG as I2C for testing. It doesn't define what it can do,
Think of JTAG as I2C for testing. It doesn't define what it can do,
just a logical interface that allows a uniform channel for communication.
See @par
@@ -17,42 +17,42 @@ See @par
and @par
http://www.inaccessnetworks.com/projects/ianjtag/jtag-intro/jtag-state-machine-large.png
The first page (among other things) shows a logical representation
describing how multiple devices are wired up using JTAG. JTAG does not
specify, data rates or interface levels (3.3V/1.8V, etc) each device can
support different data rates/interface logic levels. How to wire them
The first page (among other things) shows a logical representation
describing how multiple devices are wired up using JTAG. JTAG does not
specify, data rates or interface levels (3.3V/1.8V, etc) each device can
support different data rates/interface logic levels. How to wire them
in a compatible way is an exercise for an engineer.
Basically TMS controls which shift register is placed on the device,
between TDI and TDO. The second diagram shows the state transitions on
Basically TMS controls which shift register is placed on the device,
between TDI and TDO. The second diagram shows the state transitions on
TMS which will select different shift registers.
The first thing you need to do is reset the state machine, because when
you connect to a chip you do not know what state the controller is in,you need
to clock TMS as 1, at least 7 times. This will put you into "Test Logic
Reset" State. Knowing this, you can, once reset, then track what each
transition on TMS will do, and hence know what state the JTAG state
The first thing you need to do is reset the state machine, because when
you connect to a chip you do not know what state the controller is in,you need
to clock TMS as 1, at least 7 times. This will put you into "Test Logic
Reset" State. Knowing this, you can, once reset, then track what each
transition on TMS will do, and hence know what state the JTAG state
machine is in.
There are 2 "types" of shift registers. The Instruction shift register
and the data shift register. The sizes of these are undefined, and can
change from chip to chip. The Instruction register is used to select
which Data register/data register function is used, and the data
There are 2 "types" of shift registers. The Instruction shift register
and the data shift register. The sizes of these are undefined, and can
change from chip to chip. The Instruction register is used to select
which Data register/data register function is used, and the data
register is used to read data from that function or write data to it.
Each of the states control what happens to either the data register or
Each of the states control what happens to either the data register or
instruction register.
For example, one of the data registers will be known as "bypass" this is
(usually) a single bit which has no function and is used to bypass the
chip. Assume we have 3 identical chips, wired up like the picture
and each has a 3 bit instruction register, and there are 2 known
instructions (110 = bypass, 010 = some other function) if we want to use
"some other function", on the second chip in the line, and not change
For example, one of the data registers will be known as "bypass" this is
(usually) a single bit which has no function and is used to bypass the
chip. Assume we have 3 identical chips, wired up like the picture
and each has a 3 bit instruction register, and there are 2 known
instructions (110 = bypass, 010 = some other function) if we want to use
"some other function", on the second chip in the line, and not change
the other chips we would do the following transitions.
From Test Logic Reset, TMS goes:
0 1 1 0 0
which puts every chip in the chain into the "Shift IR state"
@@ -60,7 +60,7 @@ Then (while holding TMS as 0) TDI goes:
0 1 1 0 1 0 0 1 1
which puts the following values in the instruction shift register for
which puts the following values in the instruction shift register for
each chip [110] [010] [110]
The order is reversed, because we shift out the least significant bit
@@ -70,18 +70,18 @@ first. Then we transition TMS:
which puts us in the "Shift DR state".
Now when we clock data onto TDI (again while holding TMS to 0) , the
data shifts through the data registers, and because of the instruction
registers we selected (some other function has 8 bits in its data
Now when we clock data onto TDI (again while holding TMS to 0) , the
data shifts through the data registers, and because of the instruction
registers we selected (some other function has 8 bits in its data
register), our total data register in the chain looks like this:
0 00000000 0
The first and last bit are in the "bypassed" chips, so values read from
them are irrelevant and data written to them is ignored. But we need to
The first and last bit are in the "bypassed" chips, so values read from
them are irrelevant and data written to them is ignored. But we need to
write bits for those registers, because they are in the chain.
If we wanted to write 0xF5 to the data register we would clock out of
If we wanted to write 0xF5 to the data register we would clock out of
TDI (holding TMS to 0):
0 1 0 1 0 1 1 1 1 0
@@ -91,13 +91,13 @@ clock TMS:
1 1 0
which updates the selected data register with the value 0xF5 and returns
which updates the selected data register with the value 0xF5 and returns
us to run test idle.
If we needed to read the data register before over-writing it with F5,
no sweat, that's already done, because the TDI/TDO are set up as a
circular shift register, so if you write enough bits to fill the shift
register, you will receive the "captured" contents of the data registers
If we needed to read the data register before over-writing it with F5,
no sweat, that's already done, because the TDI/TDO are set up as a
circular shift register, so if you write enough bits to fill the shift
register, you will receive the "captured" contents of the data registers
simultaneously on TDO.
That's JTAG in a nutshell. On top of this, you need to get specs for

6
doc/manual/primer/patches.txt
View File

@@ -8,7 +8,7 @@ for OpenOCD contributors who are unfamiliar with the process.
The standard method for creating patches requires developers to:
- checkout the Subversion repository (or bring a copy up-to-date),
- make the necessary modifications to a working copy,
- check with 'svn status' to see which files will be modified/added, and
- check with 'svn status' to see which files will be modified/added, and
- use 'svn diff' to review the changes and produce a patch.
It is important to minimize the changes to only those lines that contain
@@ -67,7 +67,7 @@ patch, or you can specified specific files and directories when using
<code>svn diff</code>. Overlapping patches will be discussed in the
next section.
The remainder of this section provides
The remainder of this section provides
@subsection primerpatchprops Subversion Properties
@@ -110,7 +110,7 @@ The following series of commands will work: @par
svn diff foo | unix2dos | patch -R
@endcode
This is not a bug.
This is not a bug.
@todo Does Subversion's treatment of line-endings for files marked with
svn:eol-style=native continue to pose the problems described here, or

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

@@ -115,7 +115,7 @@ Exception: The arrays.
set x "2 * 6"
set foo([expr $x]) "twelve"
**************************************************
***************************************************
=== TCL TOUR ===
@@ -133,7 +133,7 @@ This means it is evaluated when the file is parsed.
In TCL, "FOR" is a funny thing, it is not what you think it is.
Syntactically - FOR is a just a command, it is not language
construct like for(;;) in C...
construct like for(;;) in C...
The "for" command takes 4 parameters.
(1) The "initial command" to execute.
@@ -215,7 +215,7 @@ All memory regions must have 2 things:
(2) NAME( array )
And the array must have some specific names:
( <idx>, THING )
Where: THING is one of:
Where: THING is one of:
CHIPSELECT
BASE
LEN
@@ -224,7 +224,7 @@ All memory regions must have 2 things:
RWX - the access ability.
WIDTH - the accessible width.
ie: Some regions of memory are not 'word'
ie: Some regions of memory are not 'word'
accessible.
The function "address_info" - given an address should
@@ -237,14 +237,14 @@ tell you about the address.
MAJOR FUNCTION:
==
proc memread32 { ADDR }
proc memread16 { ADDR }
proc memread8 { ADDR }
proc memread32 { ADDR }
proc memread16 { ADDR }
proc memread8 { ADDR }
All read memory - and return the contents.
[ FIXME: 7/5/2008 - I need to create "memwrite" functions]
**************************************************
***************************************************
=== TCL TOUR ===
@@ -265,13 +265,13 @@ In a makefile or shell script you may have seen this:
FOO_linux = "Penguins rule"
FOO_winXP = "Broken Glass"
FOO_mac = "I like cat names"
# Pick one
BUILD = linux
#BUILD = winXP
#BUILD = mac
FOO = ${FOO_${BUILD}}
The "double [set] square bracket" thing is the TCL way, nothing more.
----
@@ -290,7 +290,7 @@ Notice this IF COMMAND - (not statement) is like this:
The "IF" command expects either 2 params, or 4 params.
=== Sidebar: About "commands" ===
Take a look at the internals of "jim.c"
Look for the function: Jim_IfCoreCommand()
And all those other "CoreCommands"
@@ -298,10 +298,10 @@ The "IF" command expects either 2 params, or 4 params.
You'll notice - they all have "argc" and "argv"
Yea, the entire thing is done that way.
IF is a command. SO is "FOR" and "WHILE" and "DO" and the
others. That is why I keep using the phase it is a "command"
=== END: Sidebar: About "commands" ===
Parameter 1 to the IF command is expected to be an expression.
@@ -315,7 +315,7 @@ CATCH - is an error catcher.
You give CATCH 1 or 2 parameters.
The first 1st parameter is the "code to execute"
The 2nd (optional) is where to put the error message.
CATCH returns 0 on success, 1 for failure.
The "![catch command]" is self explaintory.
@@ -325,7 +325,7 @@ above, the IF command can take many parameters they just have to
be joined by exactly the words "else" or "elseif".
The 4th parameter contains:
"error [format STRING....]"
This lets me modify the previous lower level error by tacking more
@@ -346,7 +346,7 @@ string, then using "dlopen()" and "dlsym()" to look it up - and get a
function pointer - and calling the function pointer.
In this case - I execute a dynamic command. You can do some cool
tricks with interpretors.
tricks with interpretors.
----------
@@ -380,7 +380,7 @@ Some assumptions:
The "CHIP" file has defined some variables in a proper form.
ie: AT91C_BASE_US0 - for usart0,
ie: AT91C_BASE_US0 - for usart0,
AT91C_BASE_US1 - for usart1
... And so on ...
@@ -419,9 +419,9 @@ with the generated list of commands for the entire USART.
With that little bit of code - I now have a bunch of functions like:
show_US0, show_US1, show_US2, .... etc ...
And show_US0_MR, show_US0_IMR ... etc...
And - I have this for every USART... without having to create tons of
boiler plate yucky code.

8
doc/manual/release.txt
View File

@@ -113,7 +113,7 @@ tags and incrementing the version.
The OpenOCD release process must be carried out on a periodic basis, so
the project can realize the benefits presented in answer to the question,
@ref releasewhy.
@ref releasewhy.
Starting with the 0.2.0 release, the OpenOCD project should produce a
new minor release every month or two, with a major release once a year.
@@ -132,7 +132,7 @@ beginning of the development cycle through the delivery of the new
release. This section presents guidelines for scheduling key points
where the community must be informed of changing conditions.
If T is the time of the next release, then the following schedule
If T is the time of the next release, then the following schedule
might describe some of the key milestones of the new release cycle:
- T minus one month: start of new development cycle
@@ -190,7 +190,7 @@ Even with the release script, some steps require clear user intervention
The following steps should be followed to produce each release:
-# Produce final patches to the trunk (or release branch):
-# Finalize @c NEWS file to describe the changes in the release
-# Finalize @c NEWS file to describe the changes in the release
- This file is Used to automatically post "blurbs" about the project.
- This material should be produced during the development cycle.
- Add a new item for each @c NEWS-worthy contribution, when committed.
@@ -208,7 +208,7 @@ svn cp .../trunk .../branches/${RELEASE_BRANCH}
svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
@endverbatim
- For bug-fix releases produced in their respective branch, a tag
should be created in the repository:
should be created in the repository:
@verbatim
svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
@endverbatim

10
doc/manual/scripting.txt
View File

@@ -5,7 +5,7 @@
The scripting support is intended for developers of OpenOCD.
It is not the intention that normal OpenOCD users will
use tcl scripting extensively, write lots of clever scripts,
or contribute back to OpenOCD.
or contribute back to OpenOCD.
Target scripts can contain new procedures that end users may
tinker to their needs without really understanding tcl.
@@ -31,7 +31,7 @@ Default implementation of procedures in tcl/procedures.tcl.
file format and structure of serialnumber. Tcl allows
an argument to consist of e.g. a list so the structure of
the serial number is not limited to a single string.
- reset handling. Precise control of how srst, trst &
- reset handling. Precise control of how srst, trst &
tms is handled.
- replace some parts of the current command line handler.
This is only to simplify the implementation of OpenOCD
@@ -42,7 +42,7 @@ Default implementation of procedures in tcl/procedures.tcl.
that return machine readable output. These low level tcl
functions constitute the tcl api. flash_banks is such
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
of OpenOCD. The output from flash_banks may not be
in the preferred form for the client. The client then
@@ -50,8 +50,8 @@ Default implementation of procedures in tcl/procedures.tcl.
or b) write a small piece of tcl to output the
flash_banks output to a more suitable form. The latter may
be simpler.
@section scriptingexternal External scripting
The embedded Jim Tcl interpreter in OpenOCD is very limited

16
doc/manual/server.txt
View File

@@ -32,14 +32,14 @@ high-level interface to OpenOCD, because they only had two choices:
- the ablity to write a complex internal commands: native 'commands'
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
with a script language:
-# <b>Internal</b>: simple, small, and self-contained.
-# <b>Cross Language</b>: script friendly front-end
-# <b>Cross Host</b>: GUI Host interface
-# <b>Cross Debugger</b>: GUI-like interface
What follows hopefully shows how the plans to solve these problems
materialized and help to explain the grand roadmap plan.
@@ -64,7 +64,7 @@ file, allowing OpenOCD to avoid the spider web of dependent packages.
The TCL Server port was added in mid-2008. With embedded TCL, we can
write scripts internally to help things, or we can write "C" code that
interfaces well with TCL.
interfaces well with TCL.
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,
@@ -81,7 +81,7 @@ terse, simple ASCII protocols that are emensely parsable by a script.
Thus, the TCL server -- a 'machine' type socket interface -- was added
with the hope was it would output simple "name-value" pair type
data. At the time, simple name/value pairs seemed reasonably easier to
do at the time, though Maybe it should output JSON;
do at the time, though Maybe it should output JSON;
See here:
@@ -101,11 +101,11 @@ How do we solve that problem?
For example, Cygwin can be painful, Cygwin GUI packages want X11
to be present, crossing the barrier between MinGW and Cygwin is
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
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
devince with a built-in HTTP server. Later, they were willing to both
@@ -169,7 +169,7 @@ the Socket Approach is used.
During 2008, Duane Ellis created some TCL scripts to display peripheral
register contents. For example, look at the sam7 TCL scripts, and the
stm32 TCL scripts. The hope was others would create more.
stm32 TCL scripts. The hope was others would create more.
A good example of this is display/view the peripheral registers on
@@ -215,7 +215,7 @@ 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
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.
Many devlopers use Emacs (possibly with GUD mode) or vim and will not
Many devlopers use Emacs (possibly with GUD mode) or vim and will not
accept such an interface. The next developer reading this might be
using Insight (GDB-TK) - and somebody else - DDD..

6
doc/manual/style.txt
View File

@@ -149,7 +149,7 @@ comments.
* in blocks such as the one in which this example appears in the Style
* Guide. See the Doxygen Manual for the full list of commands.
*
* @param foo For a function, describe the parameters (e.g. @a foo).
* @param foo For a function, describe the parameters (e.g. @a foo).
* @returns The value(s) returned, or possible error conditions.
*/
@endverbatim
@@ -229,7 +229,7 @@ This file contains the @ref pagename page.
@endverbatim
For an example, the Doxygen source for this Style Guide can be found in
@c doc/manual/style.txt, alongside other parts of The Manual.
@c doc/manual/style.txt, alongside other parts of The Manual.
*/
/** @page styletexinfo Texinfo Style Guide
@@ -344,7 +344,7 @@ Likewise, the @ref primerlatex for using this guide needs to be completed.
This page provides some style guidelines for using Perl, a scripting
language used by several small tools in the tree:
-# Ensure all Perl scripts use the proper suffix (@c .pl for scripts, and
-# Ensure all Perl scripts use the proper suffix (@c .pl for scripts, and
@c .pm for modules)
-# Pass files as script parameters or piped as input:
- Do NOT code paths to files in the tree, as this breaks out-of-tree builds.

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

@@ -37,7 +37,7 @@ mailing list
@section targetnotarmsupport Target Support
target.h is relatively CPU agnostic and
the intention is to move in the direction of less
the intention is to move in the direction of less
instruction set specific.
Non-CPU targets are also supported, but there isn't
@@ -56,7 +56,7 @@ OpenOCD does not today have targets that use non-JTAG.
The actual physical layer is a relatively modest part
of the total OpenOCD system.
@section targetnotarmppc PowerPC
there exists open source implementations of powerpc