I couldn't believe my eyes when I saw what the bug was. irscan
has *always* been broken. I checked as far back as svn 345.
A couple of possible explanations:
- irscan has never really been used
- events have somehow conspired to hide the bugs
- I'm missing something
Known problems in irscan:
-
Fix committed.
irscan has always been badly broken. I wonder if it has
ever been used
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
I've committed a fix in 1753 for memory corruption introduced in 1730.
Thanks for bisecting to the offending release. This is definitely a case
of where numerous small commits saved my butt.
Hopefully this covers the problem that you are seing, but I don't
have your precise setup so I can't run
I've committed a fix in 1738 for memory corruption introduced in 1730.
Thanks for bisecting to the offending release. This is definitely a case
of where numerous small commits saved my butt.
Hopefully this covers the problem that you are seing.
--
Øyvind Harboe
Embedded software and hardware
On Tuesday 12 May 2009, Øyvind Harboe wrote:
I think we should be extremely careful about defining public interfaces.
Defining is less of an issue than committing to... :)
Especially since the JTAG API still (yes still! the hard bits are done
though) needs work cleanup.
Again I'll mention
On Tue, May 12, 2009 at 6:10 PM, David Brownell davi...@pacbell.net wrote:
On Tuesday 12 May 2009, Ųyvind Harboe wrote:
I think we should be extremely careful about defining public interfaces.
Defining is less of an issue than committing to... :)
Especially since the JTAG API still (yes
On Tue, May 12, 2009 at 11:49 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
I think we should be extremely careful about defining public interfaces.
Especially since the JTAG API still (yes still! the hard bits are done
though) needs work cleanup.
As an old colleague of mine(Mike Sinz)
3MHz is unreliable on some units while 2MHz appears to be fine.
commit 343375ca7a3e004e02a4912b8ef660ffa991d901
Author: root r...@xanadu.home
Date: Tue May 12 12:28:58 2009 -0400
SheevaPlug down to 2MHz JTAG clock
diff --git a/src/target/interface/sheevaplug.cfg
On Tue, May 12, 2009 at 6:39 PM, Nicolas Pitre n...@cam.org wrote:
On Tue, 12 May 2009, Øyvind Harboe wrote:
I've committed a fix in 1753 for memory corruption introduced in 1730.
Thanks for bisecting to the offending release. This is definitely a case
of where numerous small commits saved
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Tuesday 12 May 2009, Øyvind Harboe wrote:
Could we make an interface driver in OpenOCD that would
be able to use the urjtag device layer?
I had similar thoughts. I thought folk more expert in
JTAG would be better to explore such things. There's
this Øyvind guy at your company, for example
On Tue, May 12, 2009 at 7:15 PM, David Brownell davi...@pacbell.net wrote:
On Tuesday 12 May 2009, Ųyvind Harboe wrote:
Could we make an interface driver in OpenOCD that would
be able to use the urjtag device layer?
I had similar thoughts. I thought folk more expert in
JTAG would be better
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Tuesday 12 May 2009, Øyvind Harboe wrote:
Another thing I'd like to see is JTAG over TCP/IP. OpenOCD
would implement a TCP/IP server TCP/IP interface...
That may seem like a non-sequitor but JTAG over TCP/IP *is*
another interface to OpenOCD which this thread is about. Or?
JTAG over
On Tue, 12 May 2009, Øyvind Harboe wrote:
On Tue, May 12, 2009 at 6:39 PM, Nicolas Pitre n...@cam.org wrote:
About performance: things are reasonable again. It takes 90 seconds to
flash 450 KB to NAND instead of 5 minutes. But in the days of rev 1520
this was like 80 seconds, so there
On Tue, 12 May 2009, David Brownell wrote:
On Tuesday 12 May 2009, Nicolas Pitre wrote:
The Kirkwood bootrom expects 4-bit ECC from NAND. This adds
4-bit ECC computation to the NAND support and uses it with SheevaPlug.
Hmm, from the outside this sounds like the 4-bit ECC in some
TI
On Tue, May 12, 2009 at 8:12 PM, Nicolas Pitre n...@cam.org wrote:
On Tue, 12 May 2009, Øyvind Harboe wrote:
On Tue, May 12, 2009 at 6:39 PM, Nicolas Pitre n...@cam.org wrote:
About performance: things are reasonable again. It takes 90 seconds to
flash 450 KB to NAND instead of 5 minutes.
On Tue, May 12, 2009 at 8:18 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
I couldn't believe my eyes when I saw what the bug was. irscan
has *always* been broken. I checked as far back as svn 345.
A couple of possible explanations:
- irscan has never really been used
- events have
Øyvind Harboe wrote:
The idea behind the the u8 * and buf stuff is to handle host endianness.
the size of the integers in the array is orthogonal to solving the endianess.
I cannot really see the need. Yes it takes a little while to learn, but
any work where you stuff bits into
Target/host big/small endianness and bit reversal is actually somewhat of a red
herring in this discussion.
jtag_add_dr_scan() scans an array of bits in/out. These bits are represented
as an array of integers where lsb is shifted out first. lsb vs. msb is
unambigious
w.r.t. host endiannes/bit
Sorry to interrupt (; I thought that I'd share my outsider's opinion
with all.
Just a while ago someone (Zach?) was talking about a need for a stable
production cycle with frequent release branches. A 0.2.0 release was
mentioned to happen after the recent perforance issues would got fixed
(in
Someone loaned me an IAR evaluation board STR712 (made by Olimex) and a
yellow IAR J-link (marked J-LINK-ARM-KS on bottom). I had seen quite a
bit of mention on this list about jlink and thought I would give it a
try. I was at r1567 on my initial try (after rebuilding with
--enable-jlink
On Tuesday 12 May 2009, Nicolas Pitre wrote:
On Tue, 12 May 2009, David Brownell wrote:
On Tuesday 12 May 2009, Nicolas Pitre wrote:
The Kirkwood bootrom expects 4-bit ECC from NAND. This adds
4-bit ECC computation to the NAND support and uses it with SheevaPlug.
Hmm, from the
On Tue, 2009-05-12 at 23:24 +0200, Freddie Chopin wrote:
Sorry to interrupt (; I thought that I'd share my outsider's opinion
with all.
Not at all. I hope more folks are willing to step up and share their
opinions; without feedback, the maintainers cannot know what you think.
Thank you for
On Tuesday 12 May 2009, Øyvind Harboe wrote:
I don't know when the cats can be herded into a 0.2 release
at this point, but I'm pretty sure it's a month away at least.
Hmm, if you don't know ... then who could?
The process *does* seem, for now, as if it's largely
commit patches to SVN without
On Tuesday 12 May 2009, Zach Welch wrote:
On Tue, 2009-05-12 at 10:32 -0700, David Brownell wrote:
[snip]
There seems to be no strong reason that OpenOCD should
always need to be told here's the only scan chain you
should expect to use ... when it could instead just
look at the scan
On Tue, 2009-05-12 at 15:49 -0700, David Brownell wrote:
On Tuesday 12 May 2009, Zach Welch wrote:
On Tue, 2009-05-12 at 10:32 -0700, David Brownell wrote:
[snip]
There seems to be no strong reason that OpenOCD should
always need to be told here's the only scan chain you
should
On Tue, 2009-05-12 at 15:36 -0700, David Brownell wrote:
On Tuesday 12 May 2009, Øyvind Harboe wrote:
I don't know when the cats can be herded into a 0.2 release
at this point, but I'm pretty sure it's a month away at least.
Hmm, if you don't know ... then who could?
I do. Cats can be
On Tue, 2009-05-12 at 17:21 -0700, Rick Altherr wrote:
[snip]
I had mentioned this a while back. I've been thinking through the
approach and I'm slowly settling on a C++ implementation that would
essentially be a rewrite. That said, I believe an autoconfig
mechanism could be done on
On May 12, 2009, at 3:26 PM, Zach Welch wrote:
On Tue, 2009-05-12 at 10:32 -0700, David Brownell wrote:
[snip]
There seems to be no strong reason that OpenOCD should
always need to be told here's the only scan chain you
should expect to use ... when it could instead just
look at the scan
On May 12, 2009, at 3:36 PM, David Brownell wrote:
On Tuesday 12 May 2009, Øyvind Harboe wrote:
I don't know when the cats can be herded into a 0.2 release
at this point, but I'm pretty sure it's a month away at least.
Hmm, if you don't know ... then who could?
The process *does* seem, for
On May 12, 2009, at 5:48 PM, Zach Welch wrote:
On Tue, 2009-05-12 at 17:21 -0700, Rick Altherr wrote:
[snip]
I had mentioned this a while back. I've been thinking through the
approach and I'm slowly settling on a C++ implementation that would
essentially be a rewrite. That said, I believe
On Tuesday 12 May 2009, Rick Altherr wrote:
On May 12, 2009, at 3:36 PM, David Brownell wrote:
On Tuesday 12 May 2009, Øyvind Harboe wrote:
I don't know when the cats can be herded into a 0.2 release
at this point, but I'm pretty sure it's a month away at least.
Hmm, if you don't
On Tue, 2009-05-12 at 08:02 -0700, David Brownell wrote:
On Tuesday 12 May 2009, Zach Welch wrote:
+ Which do we want: jtag.h or jtag/jtag.h? **
openocd/jtag.h since there are other jtag projects
working to provide a library interface (e.g. urjtag).
I grok and agree. That said, I think
On Tue, 2009-05-12 at 17:59 -0400, Gene Smith wrote:
Someone loaned me an IAR evaluation board STR712 (made by Olimex) and a
yellow IAR J-link (marked J-LINK-ARM-KS on bottom). I had seen quite a
bit of mention on this list about jlink and thought I would give it a
try. I was at r1567 on
On Tuesday 12 May 2009, Magnus Lundin wrote:
David Brownell wrote:
Zack's list seemed useful in terms of having some
kind of direction be defined. But that's distinct
from defining release criteria, or merge criteria.
The old list, or the new rebuild everything into loadable
modules
On May 12, 2009, at 6:09 PM, David Brownell wrote:
Zack's list seemed useful in terms of having some
kind of direction be defined. But that's distinct
from defining release criteria, or merge criteria.
Yup. A todo list is great, but we need a more rigid definition of
what need to be
Right. I think some patches should certainly be able
to fit into the keep that in the -next queue category.
Effective review is probably not easy here; who knows
JTAG well enough to contribute non-cosmetic feedback?
Actually, a fair number of us _do_ know JTAG fairly well.
That's
David Brownell wrote:
Right. I think some patches should certainly be able
to fit into the keep that in the -next queue category.
Effective review is probably not easy here; who knows
JTAG well enough to contribute non-cosmetic feedback?
Actually, a fair number of us _do_ know JTAG
39 matches
Mail list logo
