Hi,
here is a small patch to add some documentation for the mips_m4k target
options.
I've also added the arm11 target to the targets list to bring the list
up to date wrt trunk. (but no options docs since I don't know that
target).
Cheers,
John McCarthy.
Index: doc/openocd.texi
Does the failure actually begin happening when you use r826 or is that
when you start getting the warning about the GDB alive packet? The
warning message is actually fairly benign. If the failure starts with
that revision, it helps narrow down the problem. That said, the
various patches
> Yes, the main intent of Doxygen is to build documentation from the source
> code. You _can_ abuse it, however, to build documentation that isn't about
> the API. It may not be worth the trouble, but is an option. Instead, we
> could use a TCL script that asks for the available target types and
hey guys,
looks like the point of failure is svn revision 826 where the gdb keep
alive messages are added to avoid "cryptic error messages" (from the
change log).
This is the error from 826
826 failure on load:
Open On-Chip Debugger 1.0 (2008-11-04-18:19) svn:826
$URL: http://svn.berlios.de/svnr
On Nov 4, 2008, at 8:14 AM, Øyvind Harboe wrote:
A thought in this direction is to use Doxygen to generate
documentation from
source code comments. It keeps the documentation close to the code
so it is
more likely to be up to date and the final output form can be
similar to
what we have
Committed.
Index: C:/workspace/openocd/src/target/arm7_9_common.c
===
--- C:/workspace/openocd/src/target/arm7_9_common.c (revision 1131)
+++ C:/workspace/openocd/src/target/arm7_9_common.c (working copy)
@@ -2016,9 +2016,11
> A thought in this direction is to use Doxygen to generate documentation from
> source code comments. It keeps the documentation close to the code so it is
> more likely to be up to date and the final output form can be similar to
> what we have today. Some areas of the docs, like the getting st
On Nov 4, 2008, at 3:08 AM, Øyvind Harboe wrote:
I've committed the attached patch to get the ball rolling on how
we can make it easier to figure out what targets OpenOCD supports.
The general idea is that there should be a command which
will print in tabular form the supported CPUs and what o
I've committed the attached patch to get the ball rolling on how
we can make it easier to figure out what targets OpenOCD supports.
The general idea is that there should be a command which
will print in tabular form the supported CPUs and what options that should
be used so as to get the user star
Committed the below to FAQ.
### Eclipse Workspace Patch 1.0
#P openocd
Index: doc/openocd.texi
===
--- doc/openocd.texi(revision 1117)
+++ doc/openocd.texi(working copy)
@@ -2093,6 +2093,22 @@
@chapter FAQ
@cindex faq
@enum
2008/11/3 Øyvind Harboe <[EMAIL PROTECTED]>
> On Mon, Nov 3, 2008 at 8:06 PM, Norbert Unterberg <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> > We updated OpenOCD from the Yagarto r717 version to version 994, running
> on
> > windows.
> > The problem is that OpenOCD does not longer recognize windows
> The attached patch makes the target syntax parsing much more robust and
> makes the variant optional again.
Committed.
Thanks!
Added you to the copyright at the top of the files. Your patches accumulatively
are undeniably non-trivial.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 AR
12 matches
Mail list logo
