This patch is a very simple test code, and more important,
it provides the information about low-level operations, so we
can track the problems.
For a generic SWJ implementation, just use 2 commands:
swj_sequence_out and swj_sequence_in, which can be
more easily implemented by other dongles
Hello
I am using the line: ./configure --disable-werror --disable-shared
--enable-ft2232_libftdi to build openocd 0.2.0 for windows using
Cygwin.
The script stops with: checking Build Link with libftdi..
configure: error: Cannot build run test program using libftdi
If I edit the
I was using svn and msys tools. I've moved to git. Hope this one will be
more usefull.
Short description:
BUG: Stack corruption when reading Intel Hex image file whith more the 128
sections
- Franck
-Message d'origine-
De : David Brownell [mailto:davi...@pacbell.net]
Envoyé : mardi
On Wednesday 28 October 2009, Franck HERESON wrote:
I was using svn and msys tools. I've moved to git. Hope this one will be
more usefull.
Fix merged, thanks.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
FYI, I've committed some patches removing needless
- function exports, when nothing outside the file
uses those functions; and
- forward declarations, sometimes reordering code
The affected files were Cortex-M3 and ARM926.
Not marking code (or data) static is sloppy, and hides
true
I did rmmod ehci_hcd and the OHCI driver took over. In full speed USB mode,
however, OpenOCD could not validate the JTAG chain, let alone reach reset
init. A complete debug log is attached, containing verbose USB and JTAG
communications messages.
I'll try to test it on another computer and
If it fails for you with OHCI, I'd expect you have a fairly clean
failure mode and that using a fullspeed hub won't change anything.
Now, one thing that's interesting is that you seem to have gotten
a *different* failure mode at full speed. Suggesting there are
two different bugs associated with
On Wednesday 28 October 2009, David Brownell wrote:
Warn : 262 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode
after end of chain: 481 0x807f8000
Warn : 263 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode
after end of chain: 513 0x80003018
And another hiccup
And forward declarations should only really be used
when they're unavoidable ... they clutter the code.
It's a shame that C couldn't get rid of the requirement to
declare fn's before they are used...
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG
On Tuesday 27 October 2009, Øyvind Harboe wrote:
int target-type-get_interface(int id, void **interface);
The ID is a unique ID across OpenOCD. The interface can be
either a single fn pointer or a structure which contains a list
of fn pointers.
You must like COM ... this is the
On Wednesday 28 October 2009, Øyvind Harboe wrote:
And forward declarations should only really be used
when they're unavoidable ... they clutter the code.
It's a shame that C couldn't get rid of the requirement to
declare fn's before they are used...
You don't have to declare them if you
Hello,
I am using standard configuration files except for the crystal frequency
which I have to set to 14675 to match my hardware and my openocd.cfg looks
like the following:
source [find interface/jtagkey-tiny.cfg]
source [find target/lpc2103.cfg]
Then when I run open openocd in the command
On Wed, Oct 28, 2009 at 10:45 PM, David Brownell davi...@pacbell.net wrote:
On Tuesday 27 October 2009, Øyvind Harboe wrote:
int target-type-get_interface(int id, void **interface);
The ID is a unique ID across OpenOCD. The interface can be
either a single fn pointer or a structure which
On Wed, Oct 28, 2009 at 10:52 PM, David Brownell davi...@pacbell.net wrote:
On Wednesday 28 October 2009, Řyvind Harboe wrote:
And forward declarations should only really be used
when they're unavoidable ... they clutter the code.
It's a shame that C couldn't get rid of the requirement to
On Wed, 2009-10-28 at 11:18 -0700, David Brownell wrote:
FYI, I've committed some patches removing needless
- function exports, when nothing outside the file
uses those functions; and
- forward declarations, sometimes reordering code
The affected files were Cortex-M3 and ARM926.
Is this for 0.3.0 or 0.4.0? I have ~50 patches and at least one or two
will probably have minor conflicts with yours. I also am looking at
doing a ton more cleanup like the stuff you have done, but I am waiting
until a) we ship 0.3.0 and b) I get my current series in the tree.
If I had
On Wed, 2009-10-28 at 23:54 +0100, Øyvind Harboe wrote:
Is this for 0.3.0 or 0.4.0? I have ~50 patches and at least one or two
will probably have minor conflicts with yours. I also am looking at
doing a ton more cleanup like the stuff you have done, but I am waiting
until a) we ship
On Wednesday 28 October 2009, Zach Welch wrote:
Is this for 0.3.0 or 0.4.0?
I checked it in for 0.3.x ... on the grounds that, as I noted,
it's cleanup that can't create bugs. Doesn't change code flow.
And there's no evident plan for 0.3.x anyway; I've been kind
of hoping we'd have cut an RC
On Wednesday 28 October 2009, Øyvind Harboe wrote:
I would like to see:
- 0.3 out of the door. Shut down sf master for anything but
bugfixes as of friday 30. to wed 4.? Cut release nov 5.?
As of Friday 12:01 AM UTC? Making it Thursday 5:01 pm PST?
Sure. In fact, tag it as 0.3.0-rc1 ?
The
On Wednesday 28 October 2009, Zach Welch wrote:
I am becoming fairly discouraged by the ongoing high-pace use of the
central repository, seeing this type of commit pushed without sufficient
review period. Are we trying for 0.3.0, or not?!?
I was kind of expecting you to cut an RC some time
On Wed, 28 Oct 2009, David Brownell wrote:
On Wednesday 28 October 2009, Zach Welch wrote:
I am becoming fairly discouraged by the ongoing high-pace use of the
central repository, seeing this type of commit pushed without sufficient
review period. Are we trying for 0.3.0, or not?!?
I
On Wednesday 28 October 2009, Nicolas Pitre wrote:
On Wed, 28 Oct 2009, David Brownell wrote:
On Wednesday 28 October 2009, Zach Welch wrote:
Are we trying for 0.3.0, or not?!?
I was kind of expecting you to cut an RC some time ago;
so I've been wondering the same thing ...
OK
On Wednesday 28 October 2009, FangfangLi wrote:
Dear Sir:
for the bellow statement:
SDR 3 TDI (5) TDO (2);
That's sneaky ... including a test report with a bug report!
In function :svf_copy_hexstring_to_binary
// check valid
if (str_len 0 || (ch ~((1 (4 - (bit_len %
On Wed, 2009-10-28 at 21:25 -0700, David Brownell wrote:
On Wednesday 28 October 2009, Nicolas Pitre wrote:
On Wed, 28 Oct 2009, David Brownell wrote:
On Wednesday 28 October 2009, Zach Welch wrote:
Are we trying for 0.3.0, or not?!?
I was kind of expecting you to cut an RC
Hi all,
OpenOCD has released its first -rc packages for testing: 0.3.0-rc0.
This version has been tagged in Git as 'v0.3.0-rc0'.
By posting these packages on SourceForge and BerliOS, we hope users will
test them and report problems to this list, so the final 0.3.0 release
do not have lingering
Hi all,
Please check the NEWS file to ensure that it notes everything worthy of
mention for 0.3.0 release. David Brownell and others have done an
excellent job of maintaining it during this release cycle, but some
things may have slipped past without being noted there: changes to
scripting
Hi all,
I want to suggest that the 0.4.0 development cycle start from the
beginning with the -rc0 tag (in addition to the -dev tag). This measure
helps ensure monotonicity of OpenOCD's version (from the perspective of
package manager sorting algorithms) for packages derived during this
series.
27 matches
Mail list logo
