Hmm,
So i looked into the code and it would appear to be a bug.
ocd_mem2array is implemented via jim_mem2array which eventually calls
target_mem2array. When this happens, I am pretty confident if
ocd_mem2array works, that argc will be 5.
BUT
if I use omap3.cpu mem2array, this is implemented
Øyvind Harboe wrote:
>> Well, since it is more than five days old I suppose it is dead fish.
>>
>
> I could have been more precise to say: it is much more work to
> apply a patch later than sooner, ignoring the risk.
>
> It's balance.
>
>
>> But I can tell you that all the state transition
Howdy,
I have a script that goes:
proc omap3_ReadDebugRegister { reg_num } {
# read the value of the debug register reg_num at address reg_num << 2
omap3.cpu mem2array dataval 32 [expr "0x54011000 + $reg_num * 4"] 1
}
It errors and crashes openocd with the following message:
Runtime error,
>> Example: there was a patch a while back (from Dick
>> Hollenbeck) that included about 60K of ft2232 and
>> TMS sequencing updates ... and gratuitous changes
>> to whitespace, and surely other things. I don't
>> know of many projects which wouldn't also reject
>> such patches with "please split
> Well, since it is more than five days old I suppose it is dead fish.
I could have been more precise to say: it is much more work to
apply a patch later than sooner, ignoring the risk.
It's balance.
> But I can tell you that all the state transition stuff works well, both
> in 7 state version
On Wed, May 13, 2009 at 12:26 AM, 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
>> loo
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
> > 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 wel
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 d
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
>
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 o
On Tue, 2009-05-12 at 08:02 -0700, David Brownell wrote:
> On Tuesday 12 May 2009, Zach Welch wrote:
> > + Which do we want: or ? **
>
> since there are other jtag projects
> working to provide a library interface (e.g. urjtag).
I grok and agree. That said, I think that such would require so
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, i
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 an
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 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 cha
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 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
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 now, as
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
> >
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 th
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" witho
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 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 chain it finds, then autoconfigure, in
> common
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,
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 config
One of the reasons that plans change dramatically is that
suddenly we have resources to get stuff done :-)
We can't decide when we will have resources and what those
resources want to work on If someone steps up with
a great patch, then I'd apply it to svn head. If we need
a release branch we
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
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 orde
Ø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 b
> 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 the drscan chain needs a lot of
Øyvind Harboe wrote:
> I've been thinking about whether some helper fn's to
> use 32 bit arrays instead of 8 bit input/output might make sense.
>
> The following code is using u8 arrays:
>
> scan_field_t fields[2];
>
>u32 instruction;
> u8 instruction_buf = instruction;
>
>
I've been thinking about whether some helper fn's to
use 32 bit arrays instead of 8 bit input/output might make sense.
The following code is using u8 arrays:
scan_field_t fields[2];
u32 instruction;
u8 instruction_buf = instruction;
buf_set_u32(out_buf, 0, 32, fli
I've been pondering if an esthetic change to the JTAG API would
be useful.
The idea is to implement this as a helper fn.
Consider:
fields[0].tap = jtag_info->tap;
fields[0].num_bits = 3;
buf_set_u32(&out_addr_buf, 0, 3, ((reg_addr >> 1) & 0x6) | (RnW & 0x1));
fiel
On Tue, May 12, 2009 at 8:59 PM, Andreas Fritiofson
wrote:
> On Tue, May 12, 2009 at 8:18 AM, Øyvind Harboe
> 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:
>>
>> - i
On Tue, May 12, 2009 at 8:18 AM, Øyvind Harboe 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 somehow conspired to h
On Tue, May 12, 2009 at 8:12 PM, Nicolas Pitre wrote:
> On Tue, 12 May 2009, Øyvind Harboe wrote:
>
>> On Tue, May 12, 2009 at 6:39 PM, Nicolas Pitre wrote:
>> > About performance: things are reasonable again. It takes 90 seconds to
>> > flash 450 KB to NAND instead of 5 minutes. But in the da
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
>
On Tue, 12 May 2009, Øyvind Harboe wrote:
> On Tue, May 12, 2009 at 6:39 PM, Nicolas Pitre 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 is stil
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 ove
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, 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 DaVinci family chips: 10 bytes ECC per 512 bytes dat
On Tue, May 12, 2009 at 7:15 PM, David Brownell 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 to explore s
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
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 Tue, May 12, 2009 at 6:39 PM, Nicolas Pitre 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 my b
The Kirkwood bootrom expects 4-bit ECC from NAND. This adds
4-bit ECC computation to the NAND support and uses it with SheevaPlug.
(patch attached)
Nicolas
diff --git a/src/flash/Makefile.am b/src/flash/Makefile.am
index 7895edc..e5b76cb 100644
--- a/src/flash/Makefile.am
+++ b/src/flash/Makefi
3MHz is unreliable on some units while 2MHz appears to be fine.
commit 343375ca7a3e004e02a4912b8ef660ffa991d901
Author: root
Date: Tue May 12 12:28:58 2009 -0400
SheevaPlug down to 2MHz JTAG clock
diff --git a/src/target/interface/sheevaplug.cfg
b/src/target/interface/sheevaplug.cfg
inde
On Tue, May 12, 2009 at 11:49 AM, Øyvind Harboe 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) said: “Programmin
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 my butt.
>
> Hopefully this covers the problem that you are sein
On Tue, May 12, 2009 at 6:10 PM, David Brownell 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 still! the
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 m
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) said: “Programming is
like sex: one mistake and you have to support it for the rest
On Tuesday 12 May 2009, Zach Welch wrote:
> + Which do we want: or ? **
since there are other jtag projects
working to provide a library interface (e.g. urjtag).
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://l
Hi all,
Despite what it may seem, my recent changes to clean up the header files
were not superficial. They are part of a strategy to create a version
of libopenocd that can be considered stable enough for production
development of high-level applications (e.g. custom GUIs).
Since I have hit t
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 c
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 t
57 matches
Mail list logo
