mynewt-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ad...@apache.org
Subject [26/51] [partial] incubator-mynewt-site git commit: remove untarred files for openocd
Date Thu, 16 Jun 2016 21:57:30 GMT
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0a2f3c5b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/server.txt
----------------------------------------------------------------------
diff --git a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/server.txt b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/server.txt
deleted file mode 100755
index 3c2fbd0..0000000
--- a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/server.txt
+++ /dev/null
@@ -1,316 +0,0 @@
-/** @page serverdocs OpenOCD Server APIs
-
-OpenOCD provides support for implementing different types of servers.
-Presently, the following servers have APIs that can be used.
-
-  - @subpage servergdb
-  - @subpage servertelnet
-  - @subpage serverhttp
-
-@section serverdocsoverview Overview
-
-What follows is a development history, and describes some of the intent
-of why certain features exist within OpenOCD along with the reasoning
-behind them.
-
-This roadmap section was written May 2009 - about 9 to 12 months
-after some of this work had started, it attempts to document some of
-the reasons why certain features exist within OpenOCD at that time.
-
-@section serverdocsbg Background
-
-In early 2008, Oyvind Harboe and Duane Ellis had talked about how to
-create a reasonable GUI for OpenOCD - something that is non-invasive,
-simple to use and maintain, and does not tie OpenOCD to many other
-packages.  It would be wrong to "spider web" requirements into other
-external external packages.  That makes it difficult for developers to
-write new code and creates a support nightmare.
-
-In many ways, people had talked about the need for some type of
-high-level interface to OpenOCD, because they only had two choices:
-- the ability to script: via an external program the actions of OpenOCD.
-- 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
-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.
-
-@subsection serverdocsjim Why JimTCL? The Internal Script Language
-
-At the time, the existing "command context schema" was proving itself
-insufficient.  However, the problem was also considered from another
-direction: should OpenOCD be first class and the script second class?
-Which one rules?
-
-In the end, OpenOCD won, the conclusion was that simpler will be better.
-Let the script language be "good enough"; it would not need numerous
-features.  Imagine debugging an embedded Perl module while debugging
-OpenOCD. Yuck.  OpenOCD already has a complex enough build system, why
-make it worse?
-
-The goal was to add a simple language that would be moderately easy to
-work with and be self-contained.  JimTCL is a single C and single H
-file, allowing OpenOCD to avoid the spider web of dependent packages.
-
-@section serverdocstcl TCL Server Port
-
-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.
-
-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,
-allowing simple front-ends to be (a) cross-platform (b) languag
-agnostic, and (c) easy to develop and use.
-
-Simple ASCII protocols are easy.  For example, HTTP, FTP (control), and
-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
-also support a high degree of interoperability with multiple systems.
-They are not human-centric protocols; more correctly, they are rigid,
-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;
-
-See here:
-
-   http://www.mail-archive.com/openocd-development%40lists.berlios.de/msg00248.html
-
-The hope was that one could write a script in what ever language you want
-and do things with it!
-
-@section serverdocsgui GUI Like Interfaces
-
-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
-dependencies.  Sure, you may well know the WhatEver-GUI library, but
-most others will not (including the next contributer to OpenOCD).
-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.
-
-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.
-
-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
-contribute and integrate most of that work into the main tree.
-
-@subsection serverdocsother Other Options Considered
-
-What if a web browser is not acceptable ie: You want to write your own
-front gadget in Eclipse, or KDevelop, or PerlTK, Ruby, or what ever
-the latest and greatest Script De Jour is.
-
-- Option 1: Can we transport this extra data through the GDB server
-protocol? In other words, can we extend the GDB server protocol?
-No, Eclipse wants to talk to GDB directly and control the GDB port.
-
-- Option 2: SWIG front end (libopenocd): Would that work?
-
-That's painful - unless you design your api to be very simplistic -
-every language has it's own set of wack-ness, parameter marshaling is
-painful.
-
-What about "callbacks" and structures, and other mess. Imagine
-debugging that system.  When JimTCL was introduced Spencer Oliver had
-quite a few well-put concerns (Summer 2008) about the idea of "TCL"
-taking over OpenOCD.  His concern is and was: how do you debug
-something written in 2 different languages?  A "SWIG" front-end is
-unlikely to help that situation.
-
-@subsection serverdoccombined Combined: Socket & WebServer Benifits
-
-Seriously think about this question: What script language (or compiled
-language) today cannot talk directly to a socket? Every thing in the
-OpenOCD world can work a socket interface. Any host side tool can talk
-to Localhost or remote host, however one might want to make it work.
-
-A socket interface is very simple. One could write a Java application
-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
-something here.
-
-@subsection serverdocplatforms Platform Permuntations
-
-Look at some permutations where OpenOCD can run; these "just work" if
-the Socket Approach is used.
-
-
-- Linux/Cygwin/MinGw/MacOSx/FreeBSD development Host Locally
-- OpenOCD with some dongle on that host
-
-
-- Linux/Cygwin/MingW/MacOS/FreeBSD development host
-- DONGLE:  tcpip based ARM-Linux perhaps at91rm9200 or ep93xx.c, running openocd.
-
-
-- Windows cygwin/X desktop environment.
-- Linux development host (via remote X11)
-- Dongle:  "eb93xx.c" based linux board
-
-
-@subsection serverdocfuture Development Scale Out
-
-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.
-
-
-A good example of this is display/view the peripheral registers on
-your embedded target.  Lots of commercial embedded debug tools have
-this, some can show the TIMER registers, the interrupt controller.
-
-What if the chip companies behind STM32, or PIC32, AT91SAM chips -
-wanted to write something that makes working with their chip better,
-easier, faster, etc.
-
-@a Question: How can we (the OpenOCD group) make that really fancy
-stuff across multiple different host platforms?
-
-Remember: OpenOCD runs on:
--# Linux via USB,
--# ARM Linux - bit-banging GPIO pins
--# MacOSX
--# FreeBSD
--# Cygwin
--# MinGW32
--# Ecos
-
-How can we get that to work?
-
-@subsection serverdocdebug What about Debugger Plugins?
-
-Really GDB is nice, it works, but it is not a good embedded debug tool.
-OpenOCD cannot work in a GUI when one cannot get to its command line.
-Some GDB front-end developers have pedantic designs that refuse any and
-all access to the GDB command line (e.g.  http://www.kdbg.org/todo.php).
-
-The TELNET interface to OpenOCD works, but the intent of that interface
-is <b>human interaction</b>. It must remain available, developers depend
-upon it, sometimes that is the only scheme available.
-
-As a small group of developers, supporting all the platforms and
-targets in the debugger will be difficult, as there are enough problem
-with the plethora of Adapters, Chips, and different target boards.
-Yes, the TCL interface might be suitable, but it has not received much
-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
-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
-accept such an interface.  The next developer reading this might be
-using Insight (GDB-TK) - and somebody else - DDD..
-
-There is no common host-side GDB front-end method.
-
-@section serverdocschallenge Front-End Scaling
-
-Maybe we are wrong - ie: OpenOCD + some TK tool
-
-Remember: OpenOCD is often (maybe 99.9%) of the time used with
-GDB-REMOTE.  There is always some front-end package - be it command-line
-GDB under DDD, Eclipse, KDevelop, Emacs, or some other package
-(e.g. IAR tools can talk to GDB servers).  How can the OpenOCD
-developers make that fancy target display GUI visible under 5 to 10
-different host-side GDB..
-
-Sure - a <em>man on a mission</em> can make that work.  The GUI might be
-libopenocd + Perl/TK, or maybe an Eclipse Plug-in.
-That is a development support nightmare for reasons described
-above. We have enough support problems as it is with targets, adapters,
-etc.
-
-@section serverdocshttpbg HTTP Server Background
-
-OpenOCD includes an HTTP server because most development environments
-are likely contain a web browser.  The web browser can talk to OpenOCD's
-HTTP server and provide a high-level interfaces to the program.
-Altogether, it provides a universally accessible GUI for OpenOCD.
-
-@section serverdocshtml Simple HTML Pages
-
-There is (or could be) a simple "Jim TCL" function to read a memory
-location. If that can be tied into a TCL script that can modify the
-HTTP text, then we have a simple script-based web server with a JTAG
-engine under the hood.
-
-Imagine a web page - served from a small board with two buttons:
-"LED_ON" and "LED_OFF", each click - turns the LED on or OFF, a very
-simplistic idea.  Little boards with web servers are great examples of
-this: Ethernut is a good example and Contiki (not a board, an embedded
-OS) is another example.
-
-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
-each register explained in exquisit detail.
-
-For an STM32, one could create a simple HTML page, with simple
-substitution text that the simple web server use to substitute the
-HTML text JIMTCL_PEEK32( 0x12345678 ) with the value read from
-memory. We end up with an HTML page that could list the contents of
-every peripheral register on the target platform.
-
-That also is transportable, regardless of the OpenOCD host
-platform: Linux/X86, Linux/ARM, FreeBSD, Cygwin, MingW, or MacOSX.
-You could even port OpenOCD to an Android system and use it as a
-bit-banging JTAG Adapter serving web pages.
-
-@subsection serverdocshtmladv Advanced HTML Pages
-
-Java or JavaScript could be used to talk back to the TCL port.  One
-could write a Java, AJAX, FLASH, or some other developer friendly
-toolbox and get a real cross-platform GUI interface. Sure, the interface
-is not native - but it is 100% cross-platform!
-
-OpenOCD current uses simple HTML pages; others might be an Adobe FLASH
-expert, or a Java Expert.  These possibilities could allow the pages
-remain cross-platform but still provide a rich user-interface
-experience.
-
-Don't forget it can also be very simple, exactly what one developer
-can contribute, a set of very simple web pages.
-
-@subsection serverdocshtmlstatus HTTP/HTML Status
-
-As of May 2009, much of the HTML pages were contributed by Zylin AS,
-hence they continue to retain some resemblance to the ZY1000 interface.
-
-Patches would be welcome to move these parts of the system forward.
-
- */
-
-/** @page servergdb OpenOCD GDB Server API
-
-This section needs to be expanded.
-
- */
-
-/** @page servertelnet OpenOCD Telnet Server API
-
-This section needs to be expanded.
-
- */
-
-/** @page serverhttp OpenOCD http Server API
-
-This section needs to be expanded.
-
- */

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0a2f3c5b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/style.txt
----------------------------------------------------------------------
diff --git a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/style.txt b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/style.txt
deleted file mode 100755
index 54c1342..0000000
--- a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/style.txt
+++ /dev/null
@@ -1,403 +0,0 @@
-/** @page styleguide Style Guides
-
-The goals for each of these guides are:
-- to produce correct code that appears clean, consistent, and readable,
-- to allow developers to create patches that conform to a standard, and
-- to eliminate these issues as points of future contention.
-
-Some of these rules may be ignored in the spirit of these stated goals;
-however, such exceptions should be fairly rare.
-
-The following style guides describe a formatting, naming, and other
-conventions that should be followed when writing or changing the OpenOCD
-code:
-
-- @subpage styletcl
-- @subpage stylec
-- @subpage styleperl
-- @subpage styleautotools
-
-In addition, the following style guides provide information for
-providing documentation, either as part of the C code or stand-alone.
-
-- @subpage styledoxygen
-- @subpage styletexinfo
-- @subpage stylelatex
-
-Feedback would be welcome to improve the OpenOCD guidelines.
-
- */
-/** @page styletcl TCL Style Guide
-
-OpenOCD needs to expand its Jim/TCL Style Guide.
-
-Many of the guidelines listed on the @ref stylec page should apply to
-OpenOCD's Jim/TCL code as well.
-
- */
-/** @page stylec C Style Guide
-
-This page contains guidelines for writing new C source code for the
-OpenOCD project.
-
-@section styleformat Formatting Guide
-
-- remove any trailing white space at the end of lines.
-- use TAB characters for indentation; do NOT use spaces.
-- displayed TAB width is 4 characters.
-- use Unix line endings ('\\n'); do NOT use DOS endings ('\\r\\n')
-- limit adjacent empty lines to at most two (2).
-- remove any trailing empty lines at the end of source files
-- do not "comment out" code from the tree; instead, one should either:
-  -# remove it entirely (git can retrieve the old version), or
-  -# use an @c \#if/\#endif block.
-
-Finally, try to avoid lines of code that are longer than than 72-80 columns:
-
-- long lines frequently indicate other style problems:
-  - insufficient use of static functions, macros, or temporary variables
-  - poor flow-control structure; "inverted" logical tests
-- a few lines may be wider than this limit (typically format strings), but:
-  - all C compilers will concatenate series of string constants.
-  - all long string constants should be split across multiple lines.
-
-@section stylenames Naming Rules
-
-- most identifiers must use lower-case letters (and digits) only.
-  - macros must use upper-case letters (and digits) only.
-  - OpenOCD identifiers should NEVER use @c MixedCaps.
-- @c typedef names must end with the '_t' suffix.
-  - This should be reserved for types that should be passed by value.
-  - Do @b not mix the typedef keyword with @c struct.
-- use underline characters between consecutive words in identifiers
-  (e.g. @c more_than_one_word).
-
-@section stylec99 C99 Rules
-
-- inline functions
-- @c // comments -- in new code, prefer these for single-line comments
-- trailing comma allowed in enum declarations
-- designated initializers ( .field = value )
-- variables declarations should occur at the point of first use
-- new block scopes for selection and iteration statements
-- use malloc() to create dynamic arrays. Do @b not use @c alloca
-or variable length arrays on the stack. non-MMU hosts(uClinux) and
-pthreads require modest and predictable stack usage.
-
-@section styletypes Type Guidelines
-- use native types (@c int or @c unsigned) if the type is not important
-  - if size matters, use the types from \<stdint.h\> or \<inttypes.h\>:
-    - @c int8_t, @c int16_t, @c int32_t, or @c int64_t: signed types of specified size
-    - @c uint8_t, @c uint16_t, @c uint32_t, or @c uint64_t: unsigned types of specified size
-  - do @b NOT redefine @c uN types from "types.h"
-
-@section stylefunc Functions
-
-- static inline functions should be prefered over macros:
-@code
-/** do NOT define macro-like functions like this... */
-#define CUBE(x) ((x) * (x) * (x))
-/** instead, define the same expression using a C99 inline function */
-static inline int cube(int x) { return x * x * x; }
-@endcode
-- Functions should be declared static unless required by other modules
-  - define static functions before first usage to avoid forward declarations.
-- Functions should have no space between its name and its parameter list:
-@code
-int f(int x1, int x2)
-{
-	...
-	int y = f(x1, x2 - x1);
-	...
-}
-@endcode
-- Separate assignment and logical test statements.  In other words, you
-should write statements like the following:
-@code
-// separate statements should be preferred
-result = foo();
-if (ERROR_OK != result)
-	...
-@endcode
-More directly, do @b not combine these kinds of statements:
-@code
-// Combined statements should be avoided
-if (ERROR_OK != (result = foo()))
-	return result;
-@endcode
-
- */
-/** @page styledoxygen Doxygen Style Guide
-
-The following sections provide guidelines for OpenOCD developers
-who wish to write Doxygen comments in the code or this manual.
-For an introduction to Doxygen documentation,
-see the @ref primerdoxygen.
-
-@section styledoxyblocks Doxygen Block Selection
-
-Several different types of Doxygen comments can be used; often,
-one style will be the most appropriate for a specific context.
-The following guidelines provide developers with heuristics for
-selecting an appropriate form and writing consistent documentation
-comments.
-
--# use @c /// to for one-line documentation of instances.
--# for documentation requiring multiple lines, use a "block" style:
-@verbatim
-/**
- * @brief First sentence is short description.  Remaining text becomes
- * the full description block, where "empty" lines start new paragraphs.
- *
- * One can make text appear in @a italics, @b bold, @c monospace, or
- * 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).
- * @returns The value(s) returned, or possible error conditions.
- */
-@endverbatim
-  -# The block should start on the line following the opening @c /**.
-  -# The end of the block, \f$*/\f$, should also be on its own line.
-  -# Every line in the block should have a @c '*' in-line with its start:
-    - A leading space is required to align the @c '*' with the @c /** line.
-    - A single "empty" line should separate the function documentation
-      from the block of parameter and return value descriptions.
-    - Except to separate paragraphs of documentation, other extra
-      "empty" lines should be removed from the block.
-  -# Only single spaces should be used; do @b not add mid-line indentation.
--# If the total line length will be less than 72-80 columns, then
-  - The @c /**< form can be used on the same line.
-  - This style should be used sparingly; the best use is for fields:
-    @code int field; /**< field description */ @endcode
-
-@section styledoxyall Doxygen Style Guide
-
-The following guidelines apply to all Doxygen comment blocks:
-
--# Use the @c '\@cmd' form for all doxygen commands (do @b not use @c '\\cmd').
--# Use symbol names such that Doxygen automatically creates links:
-  -# @c function_name() can be used to reference functions
-    (e.g. flash_set_dirty()).
-  -# @c struct_name::member_name should be used to reference structure
-    fields in the documentation (e.g. @c flash_driver::name).
-  -# URLS get converted to markup automatically, without any extra effort.
-  -# new pages can be linked into the heirarchy by using the @c \@subpage
-    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 good Doxygen mark-up:
-  -# '\@a' (italics) should be used to reference parameters (e.g. <i>foo</i>).
-  -# '\@b' (bold) should be used to emphasizing <b>single</b> words.
-  -# '\@c' (monospace) should be used with <code>file names</code> and
-  <code>code symbols</code>, so they appear visually distinct from
-  surrounding text.
-  -# To mark-up multiple words, the HTML alternatives must be used.
--# Two spaces should be used when nesting lists; do @b not use '\\t' in lists.
--# Code examples provided in documentation must conform to the Style Guide.
-
-@section styledoxytext Doxygen Text Inputs
-
-In addition to the guidelines in the preceding sections, the following
-additional style guidelines should be considered when writing
-documentation as part of standalone text files:
-
--# Text files must contain Doxygen at least one comment block:
-  -# Documentation should begin in the first column (except for nested lists).
-  -# Do NOT use the @c '*' convention that must be used in the source code.
--# Each file should contain at least one @c \@page block.
-  -# Each new page should be listed as a \@subpage in the \@page block
-  of the page that should serve as its parent.
-  -# Large pages should be structure in parts using meaningful \@section
-  and \@subsection commands.
--# Include a @c \@file block at the end of each Doxygen @c .txt file to
-  document its contents:
-  - Doxygen creates such pages for files automatically, but no content
-    will appear on them for those that only contain manual pages.
-  - The \@file block should provide useful meta-documentation to assist
-    techincal writers; typically, a list of the pages that it contains.
-  - For example, the @ref styleguide exists in @c doc/manual/style.txt,
-    which contains a reference back to itself.
--# The \@file and \@page commands should begin on the same line as
-   the start of the Doxygen comment:
-@verbatim
-/** @page pagename Page Title
-
-Documentation for the page.
-
- */
-/** @file
-
-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.
-
- */
-/** @page styletexinfo Texinfo Style Guide
-
-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.
-It is also the reference manual for all commands and options involved
-in using them, including interface, flash, target, and other drivers.
-At this time, it is the only user-targetted documentation; everything
-else is addressing OpenOCD developers.
-
-There are two key audiences for the User's Guide, both developer based.
-The primary audience is developers using OpenOCD as a tool in their
-work, or who may be starting to use it that way.  A secondary audience
-includes developers who are supporting those users by packaging or
-customizing it for their hardware, installing it as part of some software
-distribution, or by evolving OpenOCD itself.  There is some crossover
-between those audiences.  We encourage contributions from users as the
-fundamental way to evolve and improve OpenOCD.  In particular, creating
-a board or target specific configuration file is something that many
-users will end up doing at some point, and we like to see such files
-become part of the mainline release.
-
-General documentation rules to remember include:
-
-- Be concise and clear.  It's work to remove those extra words and
-  sentences, but such "noise" doesn't help readers.
-- Make it easy to skim and browse.  "Tell what you're going to say,
-  then say it".  Help readers decide whether to dig in now, or
-  leave it for later.
-- Make sure the chapters flow well.  Presentations should not jump
-  around, and should move easily from overview down to details.
-- Avoid using the passive voice.
-- Address the reader to clarify roles ("your config file", "the board you
-  are debugging", etc.); "the user" (etc) is artificial.
-- Use good English grammar and spelling.  Remember also that English
-  will not be the first language for many readers.  Avoid complex or
-  idiomatic usage that could create needless barriers.
-- Use examples to highlight fundamental ideas and common idioms.
-- Don't overuse list constructs.  This is not a slide presentation;
-  prefer paragraphs.
-
-When presenting features and mechanisms of OpenOCD:
-
-- Explain key concepts before presenting commands using them.
-- Tie examples to common developer tasks.
-- When giving instructions, you can \@enumerate each step both
-  to clearly delineate the steps, and to highlight that this is
-  not explanatory text.
-- When you provide "how to use it" advice or tutorials, keep it
-  in separate sections from the reference material.
-- Good indexing is something of a black art.  Use \@cindex for important
-  concepts, but don't overuse it.  In particular, rely on the \@deffn
-  indexing, and use \@cindex primarily with significant blocks of text
-  such as \@subsection.  The \@dfn of a key term may merit indexing.
-- Use \@xref (and \@anchor) with care.  Hardcopy versions, from the PDF,
-  must make sense without clickable links (which don't work all that well
-  with Texinfo in any case).  If you find you're using many links,
-  read that as a symptom that the presentation may be disjointed and
-  confusing.
-- Avoid font tricks like \@b, but use \@option, \@file, \@dfn, \@emph
-  and related mechanisms where appropriate.
-
-For technical reference material:
-
-- It's OK to start sections with explanations and end them with
-  detailed lists of the relevant commands.
-- Use the \@deffn style declarations to define all commands and drivers.
-  These will automatically appear in the relevant index, and those
-  declarations help promote consistent presentation and style.
-   - It's a "Command" if it can be used interactively.
-   - Else it's a "Config Command" if it must be used before the
-     configuration stage completes.
-   - For a "Driver", list its name.
-   - Use EBNF style regular expressions to define parameters:
-     brackets around zero-or-one choices, parentheses around
-     exactly-one choices.
-   - Use \@option, \@file, \@var and other mechanisms where appropriate.
-   - Say what output it displays, and what value it returns to callers.
-   - Explain clearly what the command does.  Sometimes you will find
-     that it can't be explained clearly.  That usually means the command
-     is poorly designed; replace it with something better, if you can.
-   - Be complete:  document all commands, except as part of a strategy
-     to phase something in or out.
-   - Be correct:  review the documentation against the code, and
-     vice versa.
-- Alphabetize the \@defn declarations for all commands in each
-  section.
-- Keep the per-command documentation focussed on exactly what that
-  command does, not motivation, advice, suggestions, or big examples.
-  When commands deserve such expanded text, it belongs elsewhere.
-  Solutions might be using a \@section explaining a cluster of related
-  commands, or acting as a mini-tutorial.
-- Details for any given driver should be grouped together.
-
-The User's Guide is the first place most users will start reading,
-after they begin using OpenOCD.  Make that investment of their time
-be as productive as possible.  Needing to look at OpenOCD source code,
-to figure out how to use it is a bad sign, though it's OK to need to
-look at the User's guide to figure out what a config script is doing.
-
- */
-/** @page stylelatex LaTeX Style Guide
-
-This page needs to provide style guidelines for using LaTeX, the
-typesetting language used by The References for OpenOCD Hardware.
-Likewise, the @ref primerlatex for using this guide needs to be completed.
-
- */
-/** @page styleperl Perl Style Guide
-
-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
-   @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.
-  - If you must, then you must also use an automake rule to create the script.
--# use @c '#!/usr/bin/perl' as the first line of Perl scripts.
--# always <code>use strict</code> and <code>use warnings</code>
--# invoke scripts indirectly in Makefiles or other scripts:
-@code
-perl script.pl
-@endcode
-
-Maintainers must also be sure to follow additional guidelines:
--# Ensure that Perl scripts are committed as executables:
-    Use "<code>chmod +x script.pl</code>"
-    @a before using "<code>git add script.pl</code>"
-
- */
-/** @page styleautotools Autotools Style Guide
-
-This page contains style guidelines for the OpenOCD autotools scripts.
-
-The following guidelines apply to the @c configure.ac file:
-- Better guidelines need to be developed, but until then...
-- Use good judgement.
-
-The following guidelines apply to @c Makefile.am files:
--# When assigning variables with long lists of items:
-  -# Separate the values on each line to make the files "patch friendly":
-@code
-VAR = \
-	value1 \
-	value2 \
-	...
-	value9 \
-	value10
-@endcode
- */
-/** @file
-
-This file contains the @ref styleguide pages.  The @ref styleguide pages
-include the following Style Guides for their respective code and
-documentation languages:
-
-- @ref styletcl
-- @ref stylec
-- @ref styledoxygen
-- @ref styletexinfo
-- @ref stylelatex
-- @ref styleperl
-- @ref styleautotools
-
- */

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0a2f3c5b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target.txt
----------------------------------------------------------------------
diff --git a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target.txt b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target.txt
deleted file mode 100755
index 7e9767f..0000000
--- a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-/** @page targetdocs OpenOCD Target APIs
-
-OpenOCD provides its Target APIs to allow developers to provide trace and
-debugging support for specific device targets.  These primarily consist of
-ARM cores, but other types have been supported.  New targets should be
-developed by following or using these APIs.
-
-The Target Support module contains APIs that cover several functional areas:
-
-  - @subpage targetarm
-  - @subpage targetnotarm
-  - @subpage targetmips
-  - @subpage targetregister
-  - @subpage targetimage
-  - @subpage targettrace
-
-This section needs to be expanded.
-
-*/
-
-/** @page targetarm OpenOCD ARM Targets
-
-This section needs to describe OpenOCD's ARM target support.
-
- */
-
-/** @page targetregister OpenOCD Target Register API
-
-This section needs to describe OpenOCD's Target Register API, as
-provided by 'src/target/register.h'.
-
- */
-
-/** @page targetimage OpenOCD Target Image API
-
-This section needs to describe OpenOCD's Target Image API, as provided
-by 'src/target/image.h'.
-
- */
-
-/** @page targettrace OpenOCD Target Trace API
-
-This section needs to describe OpenOCD's Target Trace API, as provided
-by 'src/target/trace.h'.
-
- */

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0a2f3c5b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target/mips.txt
----------------------------------------------------------------------
diff --git a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target/mips.txt b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target/mips.txt
deleted file mode 100755
index 32c40b9..0000000
--- a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target/mips.txt
+++ /dev/null
@@ -1,536 +0,0 @@
-/** @page targetmips OpenOCD MIPS Targets
-
-@section ejatgmem EJTAG Memory Addresses
-
-An optional uncached and unmapped debug segment dseg (EJTAG area) appears in the address range
-0xFFFF FFFF FF20 0000 to 0xFFFF FFFF FF3F FFFF. The dseg segment thereby appears in the kseg part of the
-compatibility segment, and access to kseg is possible with the dseg segment.
-
-The dseg segment is subdivided into dmseg (EJTAG memory) segment and the drseg (EJTAG registers) segment. The
-dmseg segment is used when the probe services the memory segment. The drseg segment is used when the
-memory-mapped debug registers are accessed. Table 5-2 shows the subdivision and attributes for the segments.
-
-dseg is divided in :
-
-  - dmseg (0xFFFF FFFF FF20 0000 to 0xFFFF FFFF FF2F FFFF)
-  - drseg (0xFFFF FFFF FF30 0000 to 0xFFFF FFFF FF3F FFFF)
-
-Because the dseg segment is serviced exclusively by the EJTAG features, there
-are no physical address per se. Instead the lower 21 bits of the virtual address select
-the appropriate reference in either EJTAG memory or registers. References are not mapped through the
-TLB, nor do the accesses appear on the external system memory interface.
-
-Both of this memory segments are Uncached.
-
-On debug exception (break) CPU jumps to the beginning of dmseg. This some kind of memory shared
-between CPU and EJTAG dongle.
-
-There CPU stops (correct terminology is : stalls, because it stops it's pipeline), and is waiting for some action of dongle.
-
-If the dongle gives it instruction, CPU executes it, augments it's PC to 0xFFFF FFFF FF20 0001 - but it again points to dmseg area,
-so it stops waiting for next instruction.
-
-This will all become clear later, after reading following prerequisite chapters.
-
-@section impflags Important flags
-
-@subsection	pnnw PNnW
-
-Indicates read or write of a pending processor access:
-
-  - 0 : Read processor access, for a fetch/load access
-  - 1 : Write processor access, for a store access
-
-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),
-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)
-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.
-
-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
-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
-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).
-
-@subsection	pracc PrAcc
-
-Indicates a pending processor access and controls finishing of a pending processor access.
-
-When read:
-
-  - 0 : No pending processor access
-  - 1 : Pending processor access
-
-A write of 0 finishes a processor access if pending;
-otherwise operation of the processor is UNDEFINED
-if the bit is written to 0 when no processor access is
-pending. A write of 1 is ignored.
-
-A successful FASTDATA access will clear this bit.
-
-As noted above, on any access to dmseg, processor will stall. It waits for dongle to do some action - either to take or put some data.
-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.
-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),
-and PNnW bit is 0 (CPU does read from dmseg), and PrAcc is 1 (CPU is pending on dmseg access).
-
-@subsection spracc	SPrAcc
-
-Shifting in a zero value requests completion of the Fastdata access.
-
-The PrAcc bit in the EJTAG Control register is overwritten with zero when the access
-succeeds. (The access succeeds if PrAcc is one and the operation address is in the legal dmseg segment
-Fastdata area.)
-
-When successful, a one is shifted out. Shifting out a zero indicates a Fastdata access failure.
-Shifting in a one does not complete the Fastdata access and the PrAcc bit is unchanged. Shifting out a
-one indicates that the access would have been successful if allowed to complete and a zero indicates
-the access would not have successfully completed.
-
-@section fdreg Fastdata Register (TAP Instruction FASTDATA)
-
-The width of the Fastdata register is 1 bit.
-
-During a Fastdata access, the Fastdata register is written and read, i.e., a bit is
-shifted in and a bit is shifted out.
-
-Also during a Fastdata access, the Fastdata register value shifted in specifies whether the Fastdata
-access should be completed or not. The value shifted out is a flag that indicates whether the Fastdata access was
-successful or not (if completion was requested).
-
-@section ejtagacc EJTAG Access Implementation
-
-OpenOCD reads/writes data to JTAG via mips_m4k_read_memory() and mips_m4k_write_memory() functions defined in src/target/mips_m4k.c.
-Internally, these functions call mips32_pracc_read_mem() and mips32_pracc_write_mem() defined in src/target/mips32_pracc.c
-
-Let's take for example function mips32_pracc_read_mem32() which describes CPU reads (fetches) from dmseg (EJTAG memory) :
-
-@code
-static const uint32_t code[] = {
-														/* start: */
-	MIPS32_MTC0(15,31,0),								/* move $15 to COP0 DeSave */
-	MIPS32_LUI(15,UPPER16(MIPS32_PRACC_STACK)),			/* $15 = MIPS32_PRACC_STACK */
-	MIPS32_ORI(15,15,LOWER16(MIPS32_PRACC_STACK)),
-	MIPS32_SW(8,0,15),									/* sw $8,($15) */
-	MIPS32_SW(9,0,15),									/* sw $9,($15) */
-	MIPS32_SW(10,0,15),									/* sw $10,($15) */
-	MIPS32_SW(11,0,15),									/* sw $11,($15) */
-
-	MIPS32_LUI(8,UPPER16(MIPS32_PRACC_PARAM_IN)),		/* $8 = MIPS32_PRACC_PARAM_IN */
-	MIPS32_ORI(8,8,LOWER16(MIPS32_PRACC_PARAM_IN)),
-	MIPS32_LW(9,0,8),									/* $9 = mem[$8]; read addr */
-	MIPS32_LW(10,4,8),									/* $10 = mem[$8 + 4]; read count */
-	MIPS32_LUI(11,UPPER16(MIPS32_PRACC_PARAM_OUT)),		/* $11 = MIPS32_PRACC_PARAM_OUT */
-	MIPS32_ORI(11,11,LOWER16(MIPS32_PRACC_PARAM_OUT)),
-														/* loop: */
-	MIPS32_BEQ(0,10,8),									/* beq 0, $10, end */
-	MIPS32_NOP,
-
-	MIPS32_LW(8,0,9),									/* lw $8,0($9), Load $8 with the word @mem[$9] */
-	MIPS32_SW(8,0,11),									/* sw $8,0($11) */
-
-	MIPS32_ADDI(10,10,NEG16(1)),						/* $10-- */
-	MIPS32_ADDI(9,9,4),									/* $1 += 4 */
-	MIPS32_ADDI(11,11,4),								/* $11 += 4 */
-
-	MIPS32_B(NEG16(8)),									/* b loop */
-	MIPS32_NOP,
-                                          				/* end: */
-	MIPS32_LW(11,0,15),									/* lw $11,($15) */
-	MIPS32_LW(10,0,15),									/* lw $10,($15) */
-	MIPS32_LW(9,0,15),									/* lw $9,($15) */
-	MIPS32_LW(8,0,15),									/* lw $8,($15) */
-	MIPS32_B(NEG16(27)),								/* b start */
-	MIPS32_MFC0(15,31,0),								/* move COP0 DeSave to $15 */
-};
-@endcode
-
-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.
-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.
-
-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.
-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
-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 -
-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),
-OpenOCD has to call TAP ADDRESS instruction, which will ask CPU to give us his address within EJTAG memory :
-
-@code
-address = data = 0;
-mips_ejtag_set_instr(ejtag_info, EJTAG_INST_ADDRESS);
-mips_ejtag_drscan_32(ejtag_info, &address);
-@endcode
-
-And then, upon the results, we can conclude where it is in our code so far, so we can give it what it wants next :
-
-@code
-if ((address >= MIPS32_PRACC_PARAM_IN)
-	&& (address <= MIPS32_PRACC_PARAM_IN + ctx->num_iparam * 4))
-{
-	offset = (address - MIPS32_PRACC_PARAM_IN) / 4;
-	data = ctx->local_iparam[offset];
-}
-else if ((address >= MIPS32_PRACC_PARAM_OUT)
-	&& (address <= MIPS32_PRACC_PARAM_OUT + ctx->num_oparam * 4))
-{
-	offset = (address - MIPS32_PRACC_PARAM_OUT) / 4;
-	data = ctx->local_oparam[offset];
-}
-else if ((address >= MIPS32_PRACC_TEXT)
-	&& (address <= MIPS32_PRACC_TEXT + ctx->code_len * 4))
-{
-	offset = (address - MIPS32_PRACC_TEXT) / 4;
-	data = ctx->code[offset];
-}
-else if (address == MIPS32_PRACC_STACK)
-{
-	/* save to our debug stack */
-	data = ctx->stack[--ctx->stack_offset];
-}
-else
-{
-	/* TODO: send JMP 0xFF200000 instruction.
-		Hopefully processor jump back to start of debug vector */
-	data = 0;
-	LOG_ERROR("Error reading unexpected address 0x%8.8" PRIx32 "", address);
-	return ERROR_JTAG_DEVICE_ERROR;
-}
-@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)
-parametar from there, and saw that address of param 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).
-Obvioulsy, code is RO, and CPU can change only parameters :
-
-@code
-mips_ejtag_set_instr(ctx->ejtag_info, EJTAG_INST_DATA);
-mips_ejtag_drscan_32(ctx->ejtag_info, &data);
-
-/* Clear access pending bit */
-ejtag_ctrl = ejtag_info->ejtag_ctrl & ~EJTAG_CTRL_PRACC;
-mips_ejtag_set_instr(ctx->ejtag_info, EJTAG_INST_CONTROL);
-mips_ejtag_drscan_32(ctx->ejtag_info, &ejtag_ctrl);
-
-//jtag_add_clocks(5);
-jtag_execute_queue();
-
-if ((address >= MIPS32_PRACC_PARAM_IN)
-	&& (address <= MIPS32_PRACC_PARAM_IN + ctx->num_iparam * 4))
-{
-	offset = (address - MIPS32_PRACC_PARAM_IN) / 4;
-	ctx->local_iparam[offset] = data;
-}
-else if ((address >= MIPS32_PRACC_PARAM_OUT)
-	&& (address <= MIPS32_PRACC_PARAM_OUT + ctx->num_oparam * 4))
-{
-	offset = (address - MIPS32_PRACC_PARAM_OUT) / 4;
-	ctx->local_oparam[offset] = data;
-}
-else if (address == MIPS32_PRACC_STACK)
-{
-	/* save data onto our stack */
-	ctx->stack[ctx->stack_offset++] = data;
-}
-else
-{
-	LOG_ERROR("Error writing unexpected address 0x%8.8" PRIx32 "", address);
-	return ERROR_JTAG_DEVICE_ERROR;
-}
-@endcode
-
-CPU loops here :
-
-@code
-while (1)
-{
-	if ((retval = wait_for_pracc_rw(ejtag_info, &ejtag_ctrl)) != ERROR_OK)
-		return retval;
-
-	address = data = 0;
-	mips_ejtag_set_instr(ejtag_info, EJTAG_INST_ADDRESS);
-	mips_ejtag_drscan_32(ejtag_info, &address);
-
-	/* Check for read or write */
-	if (ejtag_ctrl & EJTAG_CTRL_PRNW)
-	{
-		if ((retval = mips32_pracc_exec_write(&ctx, address)) != ERROR_OK)
-			return retval;
-	}
-	else
-	{
-		/* Check to see if its reading at the debug vector. The first pass through
-		 * the module is always read at the vector, so the first one we allow.  When
-		 * the second read from the vector occurs we are done and just exit. */
-		if ((address == MIPS32_PRACC_TEXT) && (pass++))
-		{
-			break;
-		}
-
-		if ((retval = mips32_pracc_exec_read(&ctx, address)) != ERROR_OK)
-			return retval;
-	}
-
-	if (cycle == 0)
-		break;
-}
-@endcode
-
-and using presented R (mips32_pracc_exec_read()) and W (mips32_pracc_exec_write()) functions it reads in the code (RO) and reads and writes operands (RW).
-
-@section fdimpl OpenOCD FASTDATA Implementation
-
-OpenOCD FASTDATA write function, mips32_pracc_fastdata_xfer() is called from bulk_write_memory callback, which writes a count items of 4 bytes
-to the memory of a target at the an address given.  Because it operates only on whole words, this should be faster than target_write_memory().
-
-In order to implement FASTDATA write, mips32_pracc_fastdata_xfer() uses the following handler :
-
-@code
-uint32_t handler_code[] = {
-	/* caution when editing, table is modified below */
-	/* r15 points to the start of this code */
-	MIPS32_SW(8,MIPS32_FASTDATA_HANDLER_SIZE - 4,15),
-	MIPS32_SW(9,MIPS32_FASTDATA_HANDLER_SIZE - 8,15),
-	MIPS32_SW(10,MIPS32_FASTDATA_HANDLER_SIZE - 12,15),
-	MIPS32_SW(11,MIPS32_FASTDATA_HANDLER_SIZE - 16,15),
-	/* start of fastdata area in t0 */
-	MIPS32_LUI(8,UPPER16(MIPS32_PRACC_FASTDATA_AREA)),
-	MIPS32_ORI(8,8,LOWER16(MIPS32_PRACC_FASTDATA_AREA)),
-	MIPS32_LW(9,0,8),								/* start addr in t1 */
-	MIPS32_LW(10,0,8),								/* end addr to t2 */
-													/* loop: */
-	/* 8 */ MIPS32_LW(11,0,0),						/* lw t3,[t8 | r9] */
-	/* 9 */ MIPS32_SW(11,0,0),						/* sw t3,[r9 | r8] */
-	MIPS32_BNE(10,9,NEG16(3)),						/* bne $t2,t1,loop */
-	MIPS32_ADDI(9,9,4),								/* addi t1,t1,4 */
-
-	MIPS32_LW(8,MIPS32_FASTDATA_HANDLER_SIZE - 4,15),
-	MIPS32_LW(9,MIPS32_FASTDATA_HANDLER_SIZE - 8,15),
-	MIPS32_LW(10,MIPS32_FASTDATA_HANDLER_SIZE - 12,15),
-	MIPS32_LW(11,MIPS32_FASTDATA_HANDLER_SIZE - 16,15),
-
-	MIPS32_LUI(15,UPPER16(MIPS32_PRACC_TEXT)),
-	MIPS32_ORI(15,15,LOWER16(MIPS32_PRACC_TEXT)),
-	MIPS32_JR(15),									/* jr start */
-	MIPS32_MFC0(15,31,0),							/* move COP0 DeSave to $15 */
-};
-@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),
-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,
-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)).
-
-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.
-
-N.B. When it is executing this code in RAM, CPU will not stall on instructions, but execute all until it comes to the :
-
-@code
-MIPS32_LW(9,0,8) /* start addr in t1 */
-@endcode
-
-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
-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.
-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.
-It happens actually when CPU comes to this loop :
-
-@code
-MIPS32_LW(9,0,8),								/* start addr in t1 */
-MIPS32_LW(10,0,8),								/* end addr to t2 */
-												/* loop: */
-/* 8 */ MIPS32_LW(11,0,0),						/* lw t3,[t8 | r9] */
-/* 9 */ MIPS32_SW(11,0,0),						/* sw t3,[r9 | r8] */
-MIPS32_BNE(10,9,NEG16(3)),						/* bne $t2,t1,loop */
-@endcode
-
-and then it stalls because operand in r8 points to FASTDATA area.
-
-OpenOCD first verifies that CPU came to this place by :
-
-@code
-/* next fetch to dmseg should be in FASTDATA_AREA, check */
-address = 0;
-mips_ejtag_set_instr(ejtag_info, EJTAG_INST_ADDRESS);
-mips_ejtag_drscan_32(ejtag_info, &address);
-
-if (address != MIPS32_PRACC_FASTDATA_AREA)
-	return ERROR_FAIL;
-@endcode
-
-and then passes to CPU start and end address of the loop region for handler in RAM.
-
-In the loop in handler, CPU sees that it has to take and operand from FSTDATA area (to write it to the dst in RAM after), and so it stalls, putting PrAcc to "1".
-OpenOCD fills the data via this loop :
-
-@code
-for (i = 0; i < count; i++)
-{
-	/* Send the data out using fastdata (clears the access pending bit) */
-	mips_ejtag_set_instr(ejtag_info, EJTAG_INST_FASTDATA);
-	if ((retval = mips_ejtag_fastdata_scan(ejtag_info, write_t, buf++)) != ERROR_OK)
-		return retval;
-}
-@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,
-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.
-
-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
-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,
-and that is not stuck somewhere in the RAM, or stalling on some acces in dmseg - that would be an error :
-
-@code
-address = 0;
-mips_ejtag_set_instr(ejtag_info, EJTAG_INST_ADDRESS);
-mips_ejtag_drscan_32(ejtag_info, &address);
-
-if (address != MIPS32_PRACC_TEXT)
-	LOG_ERROR("mini program did not return to start");
-@endcode
-
-@section fdejtagspec EJTAG spec on FASTDATA access
-
-The width of the Fastdata register is 1 bit. During a Fastdata access, the Fastdata register is written and read, i.e., a bit
-is shifted in and a bit is shifted out. During a Fastdata access, the Fastdata register value shifted in specifies whether
-the Fastdata access should be completed or not. The value shifted out is a flag that indicates whether the Fastdata
-access was successful or not (if completion was requested).
-
-The FASTDATA access is used for efficient block transfers between dmseg (on the probe) and target memory (on the
-processor). An "upload" is defined as a sequence of processor loads from target memory and stores to dmseg. A
-"download" is a sequence of processor loads from dmseg and stores to target memory. The "Fastdata area" specifies
-the legal range of dmseg addresses (0xFF20.0000 - 0xFF20.000F) that can be used for uploads and downloads. The
-Data + Fastdata registers (selected with the FASTDATA instruction) allow efficient completion of pending Fastdata
-area accesses.
-During Fastdata uploads and downloads, the processor will stall on accesses to the Fastdata area. The PrAcc (processor
-access pending bit) will be 1 indicating the probe is required to complete the access. Both upload and download
-accesses are attempted by shifting in a zero SPrAcc value (to request access completion) and shifting out SPrAcc to
-see if the attempt will be successful (i.e., there was an access pending and a legal Fastdata area address was used).
-Downloads will also shift in the data to be used to satisfy the load from dmseg’s Fastdata area, while uploads will
-shift out the data being stored to dmseg’s Fastdata area.
-As noted above, two conditions must be true for the Fastdata access to succeed. These are:
-
- - PrAcc must be 1, i.e., there must be a pending processor access.
- - The Fastdata operation must use a valid Fastdata area address in dmseg (0xFF20.0000 to 0xFF20.000F).
-
-Basically, because FASTDATA area in dmseg is 16 bytes, we transfer (0xFF20.0000 - 0xFF20.000F)
-FASTDATA scan TAP instruction selects the Data and the Fastdata registers at once.
-
-They come in order :
-TDI -> | Data register| -> | Fastdata register | -> TDO
-
-FASTDATA register is 1-bit width register. It takes in SPrAcc bit which should be shifted first,
-followed by 32 bit of data.
-
-Scan width of FASTDTA is 33 bits in total : 33 bits are shifted in and 33 bits are shifted out.
-
-First bit that is shifted out is SPrAcc that comes out of Fastdata register and should give us status on FATSDATA write we want to do.
-
-@section fdcheck OpenOCD misses FASTDATA check
-
-Download flow (probe -> target block transfer) :
-
-1) Probe transfer target execution to a loop in target memory doing a fixed number of "loads" to fastdata area of dmseg (and stores to the target download destination.)
-
-2) Probe loops attempting to satisfy the loads "expected" from the target.
-   On FASTDATA access "successful" move on to next "load".
-   On FASTDATA access "failure" repeat until "successful" or timeout.
-   (A "failure" is an attempt to satisfy an access when none are pending.)
-
-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.
-
-Basically, we should do following procedure :
-
- - Download (dongle -> CPU) :
-You shift "download" DATA and FASTDATA[SPrAcc] = 0 (33 bit scan) into the target. If the value of FASTDATA[SPrAcc] shifted out is "1" then an access was pending when you started the scan and it is now complete.
-
-If SPrAcc is 0 then no access was pending to the fastdata area. (Repeat attempt to complete the access you expect for this data word. Timeout if you think the access is "long overdue" as something unexpected has happened.)
-
- - Upload (CPU -> dongle) :
-You shift "dummy" DATA and FASTDATA[SPrAcc] = 0 (33 bit scan) into the target. If the value of FASTDATA[SPrAcc] shifted out is "1" then an access was pending when you started the scan and it is now complete. The "upload" is the DATA shifted out of the target.
-
-If SPrAcc is 0 then no access was pending to the fastdata area. (Repeat attempt to complete the access you expect for this data word. Timeout if you think the access is "long overdue" as something unexpected has happened.)
-
-Basically, if checking first (before scan) if CPU is pending on FASTDATA access (PrAcc is "1"), like this
-
-@code
-wait(ready);
-do_scan();
-@endcode
-
-which is inefficient, we should do it like this :
-
-@code
-BEGIN :
-	do_scan();
-	if (!was_ready)
-	goto BEGIN;
-@endcode
-
-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)
-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,
-it is still turns in handler's loop in RAM, stalling on Fastdata area so this check :
-
-@code
-address = 0;
-mips_ejtag_set_instr(ejtag_info, EJTAG_INST_ADDRESS);
-retval = mips_ejtag_drscan_32(ejtag_info, &address);
-if (retval != ERROR_OK)
-	return retval;
-
-if (address != MIPS32_PRACC_TEXT)
-	LOG_ERROR("mini program did not return to start");
-@endcode
-
-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).
-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.
-
-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"
--# 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
--# 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.
--# 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.
--# 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.
--# 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).
--# In the end of my handler in RAM, I jumps back to begining 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".
-
-*/

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0a2f3c5b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target/notarm.txt
----------------------------------------------------------------------
diff --git a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target/notarm.txt b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target/notarm.txt
deleted file mode 100755
index 5d5be78..0000000
--- a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/manual/target/notarm.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-/** @page targetnotarm OpenOCD Non-ARM Targets
-
-This page describes outstanding issues w.r.t. non-ARM targets.
-
-@section targetnotarmflash Flash drivers
-
-The flash drivers contain ARM32 code that is used
-to execute code on the target.
-
-This needs to be handled in some CPU independent
-manner.
-
-The ocl and ecos flash drivers compile the flash
-driver code to run on the target on the developer
-machine.
-
-The ocl and ecos flash drivers should be unified
-and instructions should be written on how to
-compile the target flash drivers. Perhaps
-using automake?
-
-
-eCos has CFI driver that could probably be compiled
-for all targets. The trick is to figure out a
-way to make the compiled flash drivers work
-on all target memory maps + sort out all the
-little details
-
-@section targetnotarm32v64 32 vs. 64 bit
-
-Currently OpenOCD only supports 32 bit targets.
-
-Adding 64 bit support would be nice but there
-hasn't been any call for it in the openocd development
-mailing list
-
-@section targetnotarmsupport Target Support
-
-target.h is relatively CPU agnostic and
-the intention is to move in the direction of less
-instruction set specific.
-
-Non-CPU targets are also supported, but there isn't
-a lot of activity on it in the mailing list currently.
-An example is FPGA programming support via JTAG,
-but also flash chips can be programmed directly
-using JTAG.
-
-@section targetnotarmphy non-JTAG physical layer
-
-JTAG is not the only physical protocol used to talk to
-CPUs.
-
-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
-target manipulation, but there hasn't been a lot
-of activity in the mailing list.
-
-@section targetnotarmmips MIPS
-
-Currently OpenOCD has a MIPS target defined. This is the
-first non-ARM example of a CPU target
-
- */

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0a2f3c5b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/mdate-sh
----------------------------------------------------------------------
diff --git a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/mdate-sh b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/mdate-sh
deleted file mode 100755
index e8dfaca..0000000
--- a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/mdate-sh
+++ /dev/null
@@ -1,224 +0,0 @@
-#!/bin/sh
-# Get modification time of a file or directory and pretty-print it.
-
-scriptversion=2010-08-21.06; # UTC
-
-# Copyright (C) 1995-2014 Free Software Foundation, Inc.
-# written by Ulrich Drepper <drepper@gnu.ai.mit.edu>, June 1995
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2, or (at your option)
-# any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
-
-# As a special exception to the GNU General Public License, if you
-# distribute this file as part of a program that contains a
-# configuration script generated by Autoconf, you may include it under
-# the same distribution terms that you use for the rest of that program.
-
-# This file is maintained in Automake, please report
-# bugs to <bug-automake@gnu.org> or send patches to
-# <automake-patches@gnu.org>.
-
-if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
-  emulate sh
-  NULLCMD=:
-  # Pre-4.2 versions of Zsh do word splitting on ${1+"$@"}, which
-  # is contrary to our usage.  Disable this feature.
-  alias -g '${1+"$@"}'='"$@"'
-  setopt NO_GLOB_SUBST
-fi
-
-case $1 in
-  '')
-     echo "$0: No file.  Try '$0 --help' for more information." 1>&2
-     exit 1;
-     ;;
-  -h | --h*)
-    cat <<\EOF
-Usage: mdate-sh [--help] [--version] FILE
-
-Pretty-print the modification day of FILE, in the format:
-1 January 1970
-
-Report bugs to <bug-automake@gnu.org>.
-EOF
-    exit $?
-    ;;
-  -v | --v*)
-    echo "mdate-sh $scriptversion"
-    exit $?
-    ;;
-esac
-
-error ()
-{
-  echo "$0: $1" >&2
-  exit 1
-}
-
-
-# Prevent date giving response in another language.
-LANG=C
-export LANG
-LC_ALL=C
-export LC_ALL
-LC_TIME=C
-export LC_TIME
-
-# GNU ls changes its time format in response to the TIME_STYLE
-# variable.  Since we cannot assume 'unset' works, revert this
-# variable to its documented default.
-if test "${TIME_STYLE+set}" = set; then
-  TIME_STYLE=posix-long-iso
-  export TIME_STYLE
-fi
-
-save_arg1=$1
-
-# Find out how to get the extended ls output of a file or directory.
-if ls -L /dev/null 1>/dev/null 2>&1; then
-  ls_command='ls -L -l -d'
-else
-  ls_command='ls -l -d'
-fi
-# Avoid user/group names that might have spaces, when possible.
-if ls -n /dev/null 1>/dev/null 2>&1; then
-  ls_command="$ls_command -n"
-fi
-
-# A 'ls -l' line looks as follows on OS/2.
-#  drwxrwx---        0 Aug 11  2001 foo
-# This differs from Unix, which adds ownership information.
-#  drwxrwx---   2 root  root      4096 Aug 11  2001 foo
-#
-# To find the date, we split the line on spaces and iterate on words
-# until we find a month.  This cannot work with files whose owner is a
-# user named "Jan", or "Feb", etc.  However, it's unlikely that '/'
-# will be owned by a user whose name is a month.  So we first look at
-# the extended ls output of the root directory to decide how many
-# words should be skipped to get the date.
-
-# On HPUX /bin/sh, "set" interprets "-rw-r--r--" as options, so the "x" below.
-set x`$ls_command /`
-
-# Find which argument is the month.
-month=
-command=
-until test $month
-do
-  test $# -gt 0 || error "failed parsing '$ls_command /' output"
-  shift
-  # Add another shift to the command.
-  command="$command shift;"
-  case $1 in
-    Jan) month=January; nummonth=1;;
-    Feb) month=February; nummonth=2;;
-    Mar) month=March; nummonth=3;;
-    Apr) month=April; nummonth=4;;
-    May) month=May; nummonth=5;;
-    Jun) month=June; nummonth=6;;
-    Jul) month=July; nummonth=7;;
-    Aug) month=August; nummonth=8;;
-    Sep) month=September; nummonth=9;;
-    Oct) month=October; nummonth=10;;
-    Nov) month=November; nummonth=11;;
-    Dec) month=December; nummonth=12;;
-  esac
-done
-
-test -n "$month" || error "failed parsing '$ls_command /' output"
-
-# Get the extended ls output of the file or directory.
-set dummy x`eval "$ls_command \"\\\$save_arg1\""`
-
-# Remove all preceding arguments
-eval $command
-
-# Because of the dummy argument above, month is in $2.
-#
-# On a POSIX system, we should have
-#
-# $# = 5
-# $1 = file size
-# $2 = month
-# $3 = day
-# $4 = year or time
-# $5 = filename
-#
-# On Darwin 7.7.0 and 7.6.0, we have
-#
-# $# = 4
-# $1 = day
-# $2 = month
-# $3 = year or time
-# $4 = filename
-
-# Get the month.
-case $2 in
-  Jan) month=January; nummonth=1;;
-  Feb) month=February; nummonth=2;;
-  Mar) month=March; nummonth=3;;
-  Apr) month=April; nummonth=4;;
-  May) month=May; nummonth=5;;
-  Jun) month=June; nummonth=6;;
-  Jul) month=July; nummonth=7;;
-  Aug) month=August; nummonth=8;;
-  Sep) month=September; nummonth=9;;
-  Oct) month=October; nummonth=10;;
-  Nov) month=November; nummonth=11;;
-  Dec) month=December; nummonth=12;;
-esac
-
-case $3 in
-  ???*) day=$1;;
-  *) day=$3; shift;;
-esac
-
-# Here we have to deal with the problem that the ls output gives either
-# the time of day or the year.
-case $3 in
-  *:*) set `date`; eval year=\$$#
-       case $2 in
-	 Jan) nummonthtod=1;;
-	 Feb) nummonthtod=2;;
-	 Mar) nummonthtod=3;;
-	 Apr) nummonthtod=4;;
-	 May) nummonthtod=5;;
-	 Jun) nummonthtod=6;;
-	 Jul) nummonthtod=7;;
-	 Aug) nummonthtod=8;;
-	 Sep) nummonthtod=9;;
-	 Oct) nummonthtod=10;;
-	 Nov) nummonthtod=11;;
-	 Dec) nummonthtod=12;;
-       esac
-       # For the first six month of the year the time notation can also
-       # be used for files modified in the last year.
-       if (expr $nummonth \> $nummonthtod) > /dev/null;
-       then
-	 year=`expr $year - 1`
-       fi;;
-  *) year=$3;;
-esac
-
-# The result.
-echo $day $month $year
-
-# Local Variables:
-# mode: shell-script
-# sh-indentation: 2
-# eval: (add-hook 'write-file-hooks 'time-stamp)
-# time-stamp-start: "scriptversion="
-# time-stamp-format: "%:y-%02m-%02d.%02H"
-# time-stamp-time-zone: "UTC"
-# time-stamp-end: "; # UTC"
-# End:

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0a2f3c5b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/openocd.1
----------------------------------------------------------------------
diff --git a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/openocd.1 b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/openocd.1
deleted file mode 100755
index 4278486..0000000
--- a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/openocd.1
+++ /dev/null
@@ -1,103 +0,0 @@
-.TH "OPENOCD" "1" "November 24, 2009"
-.SH "NAME"
-openocd \- A free and open on\-chip debugging, in\-system programming and
-boundary\-scan testing tool for ARM and MIPS systems
-.SH "SYNOPSIS"
-.B openocd \fR[\fB\-fsdlcphv\fR] [\fB\-\-file\fR <filename>] [\fB\-\-search\fR <dirname>] [\fB\-\-debug\fR <debuglevel>] [\fB\-\-log_output\fR <filename>] [\fB\-\-command\fR <cmd>] [\fB\-\-pipe\fR] [\fB\-\-help\fR] [\fB\-\-version\fR]
-.SH "DESCRIPTION"
-.B OpenOCD
-is an on\-chip debugging, in\-system programming and boundary\-scan
-testing tool for various ARM and MIPS systems.
-.PP
-The debugger uses an IEEE 1149\-1 compliant JTAG TAP bus master to access
-on\-chip debug functionality available on ARM based microcontrollers or
-system-on-chip solutions. For MIPS systems the EJTAG interface is supported.
-.PP
-User interaction is realized through a telnet command line interface,
-a gdb (the GNU debugger) remote protocol server, and a simplified RPC
-connection that can be used to interface with OpenOCD's Jim Tcl engine.
-.PP
-OpenOCD supports various different types of JTAG interfaces/programmers,
-please check the \fIopenocd\fR info page for the complete list.
-.SH "OPTIONS"
-.TP
-.B "\-f, \-\-file <filename>"
-This is a shortcut for a \fB\-c "[script \fI<filename>\fB]"\fR
-command, using a search path to load the configuration file
-.IR <filename> .
-In order to specify multiple config files, you can use multiple
-.B \-\-file
-arguments. If no such \fB\-c\fR
-options are included, the first config file
-.B openocd.cfg
-in the search path will be used.
-.TP
-.B "\-s, \-\-search <dirname>"
-Add
-.I <dirname>
-to the search path used for config files and scripts.
-The search path begins with the current directory,
-then includes these additional directories before other
-components such as the standard OpenOCD script libraries.
-.TP
-.B "\-d, \-\-debug <debuglevel>"
-Set debug level. Possible values are:
-.br
-.RB "  * " 0 " (errors)"
-.br
-.RB "  * " 1 " (warnings)"
-.br
-.RB "  * " 2 " (informational messages)"
-.br
-.RB "  * " 3 " (debug messages)"
-.br
-The default level is
-.BR 2 .
-.TP
-.B "\-l, \-\-log_output <filename>"
-Redirect log output to the file
-.IR <filename> .
-Per default the log output is printed on
-.BR stderr .
-.TP
-.B "\-c, \-\-command <cmd>"
-Add the command
-.I <cmd>
-to a list of commands executed on server startup.
-Note that you will need to explicitly invoke
-.I init
-if the command requires access to a target or flash.
-.TP
-.B "\-p, \-\-pipe"
-Use pipes when talking to gdb.
-.TP
-.B "\-h, \-\-help"
-Show a help text and exit.
-.TP
-.B "\-v, \-\-version"
-Show version information and exit.
-.SH "BUGS"
-Please report any bugs on the mailing list at
-.BR openocd\-devel@lists.sourceforge.net .
-.SH "LICENCE"
-.B OpenOCD
-is covered by the GNU General Public License (GPL), version 2 or later.
-.SH "SEE ALSO"
-.BR jtag (1)
-.PP
-The full documentation for
-.B openocd
-is maintained as a Texinfo manual. If the
-.BR info
-(or
-.BR pinfo )
-and
-.BR openocd
-programs are properly installed at your site, the command
-.B info openocd
-should give you access to the complete manual.
-.SH "AUTHORS"
-Please see the file AUTHORS.
-.PP
-This manual page was written by Uwe Hermann <uwe@hermann\-uwe.de>.
-It is licensed under the terms of the GNU GPL (version 2 or later).

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0a2f3c5b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/openocd.info
----------------------------------------------------------------------
diff --git a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/openocd.info b/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/openocd.info
deleted file mode 100644
index 12c4c3f..0000000
--- a/os/tutorials/downloads/openocd-code-89bf96ffe6ac66c80407af8383b9d5adc0dc35f4/doc/openocd.info
+++ /dev/null
@@ -1,120 +0,0 @@
-This is openocd.info, produced by makeinfo version 4.8 from
-openocd.texi.
-
-INFO-DIR-SECTION Development
-START-INFO-DIR-ENTRY
-* OpenOCD: (openocd).      OpenOCD User's Guide
-END-INFO-DIR-ENTRY
-
-
-This User's Guide documents release 0.10.0-dev, dated 17 May 2016, of
-the Open On-Chip Debugger (OpenOCD).
-
-   * Copyright (C) 2008 The OpenOCD Project
-
-   * Copyright (C) 2007-2008 Spencer Oliver <spen@spen-soft.co.uk>
-
-   * Copyright (C) 2008-2010 Oyvind Harboe <oyvind.harboe@zylin.com>
-
-   * Copyright (C) 2008 Duane Ellis <openocd@duaneellis.com>
-
-   * Copyright (C) 2009-2010 David Brownell
-
-     Permission is granted to copy, distribute and/or modify this
-     document under the terms of the GNU Free Documentation License,
-     Version 1.2 or any later version published by the Free Software
-     Foundation; with no Invariant Sections, with no Front-Cover Texts,
-     and with no Back-Cover Texts. A copy of the license is included in
-     the section entitled "GNU Free Documentation License".
-
-
-Indirect:
-openocd.info-1: 1001
-openocd.info-2: 315595
-
-Tag Table:
-(Indirect)
-Node: Top1001
-Node: About3513
-Node: Developers7820
-Node: Debug Adapter Hardware11152
-Node: About Jim-Tcl22632
-Node: Running24767
-Node: OpenOCD Project Setup29935
-Ref: OpenOCD Project Setup-Footnote-149860
-Ref: OpenOCD Project Setup-Footnote-250196
-Ref: OpenOCD Project Setup-Footnote-350461
-Node: Config File Guidelines50786
-Ref: theinitboardprocedure61654
-Ref: definecputargetsworkinginsmp68444
-Ref: theinittargetsprocedure72882
-Ref: theinittargeteventsprocedure74697
-Ref: translatingconfigurationfiles76545
-Ref: Config File Guidelines-Footnote-177766
-Node: Daemon Configuration77838
-Ref: configurationstage78160
-Ref: enteringtherunstage79012
-Ref: tcpipports81457
-Ref: gdbconfiguration83950
-Ref: gdbbreakpointoverride84265
-Ref: gdbflashprogram84639
-Ref: eventpolling85866
-Node: Debug Adapter Configuration88302
-Ref: hla_interface116007
-Ref: jtagspeed120971
-Node: Reset Configuration123929
-Ref: srstandtrstissues126854
-Node: TAP Declaration138899
-Ref: enablinganddisablingtaps150087
-Ref: autoprobing152737
-Ref: TAP Declaration-Footnote-1155421
-Node: CPU Configuration155618
-Ref: targettypes158509
-Ref: targetconfiguration160911
-Ref: rtostype166295
-Ref: targetcurstate169712
-Ref: targetevents170953
-Node: Flash Commands175967
-Ref: norconfiguration177500
-Ref: flashprogrammingcommands180156
-Ref: flashprotect186284
-Ref: program186900
-Ref: flashdriverlist187157
-Ref: at91samd195868
-Ref: at91sam3198396
-Ref: nandconfiguration236801
-Ref: nanddriverlist247179
-Ref: Flash Commands-Footnote-1253571
-Ref: Flash Commands-Footnote-2253734
-Node: Flash Programming253896
-Node: PLD/FPGA Commands255395
-Node: General Commands257558
-Ref: debuglevel259607
-Ref: targetstatehandling260533
-Ref: resetcommand264288
-Ref: memoryaccess266557
-Ref: imageaccess268184
-Node: Architecture and Core Commands272674
-Ref: armhardwaretracing273144
-Ref: traceportdrivers281064
-Ref: arm9vectorcatch288962
-Ref: xscalevectorcatch297361
-Ref: softwaredebugmessagesandtracing312127
-Node: JTAG Commands315595
-Node: Boundary Scan Commands324060
-Node: Utility Commands326522
-Node: TFTP328353
-Node: GDB and OpenOCD329220
-Ref: programmingusinggdb334112
-Ref: usingopenocdsmpwithgdb335558
-Ref: gdbrtossupport337030
-Node: Tcl Scripting API338465
-Node: FAQ343296
-Ref: faqrtck343406
-Ref: faqtaporder355903
-Node: Tcl Crash Course357674
-Node: License369668
-Node: OpenOCD Concept Index392098
-Node: Command and Driver Index411594
-
-End Tag Table


Mime
View raw message