diff options
Diffstat (limited to 'doc/manual')
| -rw-r--r-- | doc/manual/flash.txt | 2 | ||||
| -rw-r--r-- | doc/manual/jtag.txt | 2 | ||||
| -rw-r--r-- | doc/manual/primer/autotools.txt | 2 | ||||
| -rw-r--r-- | doc/manual/primer/docs.txt | 4 | ||||
| -rw-r--r-- | doc/manual/primer/jtag.txt | 80 | ||||
| -rw-r--r-- | doc/manual/primer/patches.txt | 6 | ||||
| -rw-r--r-- | doc/manual/primer/tcl.txt | 38 | ||||
| -rw-r--r-- | doc/manual/release.txt | 8 | ||||
| -rw-r--r-- | doc/manual/scripting.txt | 10 | ||||
| -rw-r--r-- | doc/manual/server.txt | 16 | ||||
| -rw-r--r-- | doc/manual/style.txt | 6 | ||||
| -rw-r--r-- | doc/manual/target/notarm.txt | 4 |
12 files changed, 89 insertions, 89 deletions
diff --git a/doc/manual/flash.txt b/doc/manual/flash.txt index dbc4b94b..a9f6c2a5 100644 --- a/doc/manual/flash.txt +++ b/doc/manual/flash.txt @@ -7,7 +7,7 @@ FMI, etc.). The Flash module provides the following APIs: - - @subpage flashcfi + - @subpage flashcfi - @subpage flashnand - @subpage flashtarget diff --git a/doc/manual/jtag.txt b/doc/manual/jtag.txt index 54d0a568..8f0804ce 100644 --- a/doc/manual/jtag.txt +++ b/doc/manual/jtag.txt @@ -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) diff --git a/doc/manual/primer/autotools.txt b/doc/manual/primer/autotools.txt index 10c60006..fbf42196 100644 --- a/doc/manual/primer/autotools.txt +++ b/doc/manual/primer/autotools.txt @@ -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. diff --git a/doc/manual/primer/docs.txt b/doc/manual/primer/docs.txt index d478d81c..504da790 100644 --- a/doc/manual/primer/docs.txt +++ b/doc/manual/primer/docs.txt @@ -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 diff --git a/doc/manual/primer/jtag.txt b/doc/manual/primer/jtag.txt index 9142dadc..0c675282 100644 --- a/doc/manual/primer/jtag.txt +++ b/doc/manual/primer/jtag.txt @@ -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 diff --git a/doc/manual/primer/patches.txt b/doc/manual/primer/patches.txt index 098766eb..b24e72fa 100644 --- a/doc/manual/primer/patches.txt +++ b/doc/manual/primer/patches.txt @@ -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 diff --git a/doc/manual/primer/tcl.txt b/doc/manual/primer/tcl.txt index c10c3647..9be4a05e 100644 --- a/doc/manual/primer/tcl.txt +++ b/doc/manual/primer/tcl.txt @@ -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. diff --git a/doc/manual/release.txt b/doc/manual/release.txt index c7069717..273f228a 100644 --- a/doc/manual/release.txt +++ b/doc/manual/release.txt @@ -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 diff --git a/doc/manual/scripting.txt b/doc/manual/scripting.txt index e5b5f700..783541ca 100644 --- a/doc/manual/scripting.txt +++ b/doc/manual/scripting.txt @@ -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 diff --git a/doc/manual/server.txt b/doc/manual/server.txt index 2e5aaf3b..4310d365 100644 --- a/doc/manual/server.txt +++ b/doc/manual/server.txt @@ -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.. diff --git a/doc/manual/style.txt b/doc/manual/style.txt index 0fe33876..ef73aed6 100644 --- a/doc/manual/style.txt +++ b/doc/manual/style.txt @@ -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. diff --git a/doc/manual/target/notarm.txt b/doc/manual/target/notarm.txt index c368ed1c..5d5be78c 100644 --- a/doc/manual/target/notarm.txt +++ b/doc/manual/target/notarm.txt @@ -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 |