David Brownell a écrit :
> On Wednesday 25 November 2009, Albert ARIBAUD wrote:
>> Dean Glazeski a écrit :
>>> This patch shouldn't be necessary. I have the libftdi version working
>>> fine with current head. I think this might be an issue with mixing
>>> libraries in the configure command. I'
Oh, I got ya :). I just copy and pasted it from another file. I'll fix
that.
// Dean Glazeski
On Wed, Nov 25, 2009 at 5:53 PM, David Brownell wrote:
> On Wednesday 25 November 2009, Dean Glazeski wrote:
> > >
> > > - ARM NAND I/O interface update ... please don't add
> > > lines of '*' o
In target_type.h it's documented that the target must be
halted for add_breakpoint() ... and with slight ambiguity,
also for its add_watchpoint() sibling. So rather than
verifying that constraint in the CPU drivers, do it in the
target_add_{break,watch}point() routines.
Add minor paranoia on the
There are two names that may matter on a per-target basis.
One is a per-instance name (for example, "at91sam7s.cpu").
The other is the name of its type (for example, "arm7tdmi"),
which is shared among multiple targets.
Currently target_get_name() returns the type name, which is
misleading and is r
Several of the sites now using target_type_name() really
ought to be using an instance-specific name. Create a
function called target_name(), accessing the instance's
own (command) name.
Use it in several places that really should be displaying
instance-specific names. Also in several places whi
On Wednesday 25 November 2009, Dean Glazeski wrote:
> >
> > - ARM NAND I/O interface update ... please don't add
> > lines of '*' on the right margins, they always end
> > up getting trashed by someone who likes alternate
> > tab widths or somesuch.
> >
>
> Do you mean the lines that are b
>
> - ARM NAND I/O interface update ... please don't add
> lines of '*' on the right margins, they always end
> up getting trashed by someone who likes alternate
> tab widths or somesuch.
>
Do you mean the lines that are block comments like:
/**
* Block comment.
*/
This should be alrig
On Monday 23 November 2009, Dean Glazeski wrote:
> The new play area is http://repo.or.cz/w/openocd/dnglaze.git.
The "nand-refactor" branch reads OK, except that I'd
prefer to see too-long lines replaced not with lines
that are also-too-long, but with ones that have sane
lengths.
I should b
On Monday 23 November 2009, Dean Glazeski wrote:
> The new play area is http://repo.or.cz/w/openocd/dnglaze.git.
Looking at the "armnandio" branch ... mostly OK, but:
- ARM NAND I/O refactor code copying ... surely this
belongs in src/target/arm.c for even more general reuse?
I've been m
On Wed, 2009-11-25 at 13:08 -0800, David Brownell wrote:
> On Tuesday 24 November 2009, Zach Welch wrote:
> > On Tue, 2009-11-24 at 16:54 -0800, David Brownell wrote:
> > > On Tuesday 24 November 2009, z...@superlucidity.net wrote:
[snip]
> That said, it feels like very bad form to omit forward dec
On Wednesday 25 November 2009, Albert ARIBAUD wrote:
> Dean Glazeski a écrit :
> > This patch shouldn't be necessary. I have the libftdi version working
> > fine with current head. I think this might be an issue with mixing
> > libraries in the configure command. I've responded to the next ema
I would beg of you that you study jtag_add_dr() and jtag_add_dr_out()
in oharboe/jtag32api *before* you go down the road of thinkg about
how to put lipstick on the current fields structures...
Especially jtag_add_dr_out() has a track record of being wickedly
efficient.
--
Øyvind Harboe
http:/
On Wed, Nov 25, 2009 at 8:54 PM, David Brownell wrote:
> On Friday 20 November 2009, Ųyvind Harboe wrote:
>> > 2. Eliminating the global variable jtag_command_queue.
>> >
>> > The existing jtag_add_... commands would remain similar but would
>> > operate on a local copy of the queue. jtag_execute_
On Wed, Nov 25, 2009 at 9:33 PM, David Brownell wrote:
> On Sunday 22 November 2009, Johnny Halfmoon wrote:
>> > Consider a board:
>> >
>> > USB --> Cortex-M3 --> level shifting --> JTAG
>> >
>> ...
>> > Come up with such a board with initial "it works"
>> > firmware ... and OpenOCD could spee
Dean Glazeski a écrit :
> This patch shouldn't be necessary. I have the libftdi version working
> fine with current head. I think this might be an issue with mixing
> libraries in the configure command. I've responded to the next email
> with more information.
>
> // Dean Glazeski
Well it s
On Tuesday 24 November 2009, Zach Welch wrote:
> On Tue, 2009-11-24 at 16:54 -0800, David Brownell wrote:
> > On Tuesday 24 November 2009, z...@superlucidity.net wrote:
> > > It is an error to require other headers to be included first, so declare
> > > what we can (struct declarations) and include
On Sunday 22 November 2009, Johnny Halfmoon wrote:
> > Consider a board:
> >
> > USB --> Cortex-M3 --> level shifting --> JTAG
> >
> ...
> > Come up with such a board with initial "it works"
> > firmware ... and OpenOCD could speed things up
> > over time.
>
> Now there's an interesting proj
On Friday 20 November 2009, Øyvind Harboe wrote:
> > 2. Eliminating the global variable jtag_command_queue.
> >
> > The existing jtag_add_... commands would remain similar but would
> > operate on a local copy of the queue. jtag_execute_queue then receives
> > the pointer to that local copy as para
> Just to clarify the whole issue once more, my proposal was actually
> three different things:
These seem like good directions to explore.
I'll suggest the post-0.4.0 development cycle (January++) as a
good time to have mergeable code that starts reworking any of
this stuff. I don't think 0.4.0
On Friday 20 November 2009, Øyvind Harboe wrote:
> I'm very much against *forcing* interfaces to implement a queue
> in memory. It should be possible to execute the commands
> synchronously. The existance of a queue would make the code
> *much* less efficient on embedded devices.
We saw contrary f
On Wed, 2009-11-25 at 10:45 -0800, Zach Welch wrote:
> On Tue, 2009-11-24 at 14:02 -0800, Zach Welch wrote:
> > Hi all,
> >
> > I have finished my series to convert the tree to use the improved
> > command registration methodology. I apologize for the number of patches
> > in these series; howeve
On Tue, 2009-11-24 at 14:02 -0800, Zach Welch wrote:
> Hi all,
>
> I have finished my series to convert the tree to use the improved
> command registration methodology. I apologize for the number of patches
> in these series; however, only a handful of patches are bigger than 10K,
> and most are
I don't intend to start off an embeddedhosts.txt file
at this point.
For eCos the main thing is to have a little bit of wrapper stuff(like
for Windows) and to rein in stack usage(modest and predictable).
That's covered by the C99 style limitation on variable length
arrays on the stack and alloca.
C99 style guide changes w.r.t. stack usage and embedded hosts.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Embedded and pthreads rely on modest and predictable
stack usage.
Signed-off-by: Øyvind Harboe
---
doc/manual/style.txt |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/doc/manual/style.txt b/doc/manual/style.txt
index b4d0216..71bb5f6 100644
--- a/doc/manual/style.txt
This patch shouldn't be necessary. I have the libftdi version working fine
with current head. I think this might be an issue with mixing libraries in
the configure command. I've responded to the next email with more
information.
// Dean Glazeski
On Wed, Nov 25, 2009 at 9:43 AM, Albert Aribaud
You appear to mixing the two FTDI libraries in that configure command. If
you want to use the FTD2XX libraries, you need to use --enable-ft2232_ftd2xx
instead of --enable-ft2232_libftdi. If you want to use the libftdi that's
installed on many Linux installations, then just remove the --with-ftd2x
Edgar Grimberg wrote:
> I am using OpenOCD version 0.3.1, connected to STM32 target and the
> "default" configuration script. The STM32 flash is blank. If I try to
> "reset halt", I find the state of the CPU to be Handler HardFault:
>
>> reset halt
Could you try to remove (or comment out) the "re
Hi,
I am using OpenOCD version 0.3.1, connected to STM32 target and the
"default" configuration script. The STM32 flash is blank. If I try to
"reset halt", I find the state of the CPU to be Handler HardFault:
> reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part:
0xba00,
loody a écrit :
> dear all:
> I use configure --help, but I cannot see where I can tell openocd
> where the library of ft2232.
> I use following configure even I don't use cygwin and I use lib
> instead of device driver to compile it.
>
> ./configure --enable-ft2232_libftdi --prefix=`pwd`/build
>
Signed-off-by: Albert Aribaud
---
configure.in |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/configure.in b/configure.in
index 8ba8951..0adf014 100644
--- a/configure.in
+++ b/configure.in
@@ -932,6 +932,7 @@ if test $build_ft2232_libftdi = yes ; then
# We assume: t
dear all:
I use configure --help, but I cannot see where I can tell openocd
where the library of ft2232.
I use following configure even I don't use cygwin and I use lib
instead of device driver to compile it.
./configure --enable-ft2232_libftdi --prefix=`pwd`/build
--with-ftd2xx=/media/sdb1/softwa
Hello,
'flash erase_sector' and 'flash protect' have not been working for me
recently. Passing them the correct number of arguments (3 and 4,
respectively) returns the usage message, but passing them each one
argument less than they require crashes the program.
I believe the problem was introduce
On Wed, Nov 25, 2009 at 9:20 AM, David Brownell wrote:
> On Tuesday 24 November 2009, Ųyvind Harboe wrote:
>> The old style commands are typical commands for user interaction
>> in telnet and jim tcl commands are more oriented towards being
>> used from Jim, w.r.t. output and return values.
>
> It
On Tuesday 24 November 2009, Øyvind Harboe wrote:
> The old style commands are typical commands for user interaction
> in telnet and jim tcl commands are more oriented towards being
> used from Jim, w.r.t. output and return values.
It ought to be(come) the norm that command output can be used
from
35 matches
Mail list logo
