On Fri, May 8, 2009 at 8:53 AM, Magnus Lundin wrote:
> Ųyvind Harboe wrote:
>>>
>>> You can add your stuff for testing, ok no problem. You can put things in
>>> plase so that I can test and profile potential changes. But you are
>>> stepping on my toes by changing things I work on.
>>>
>>
>> Let
Øyvind Harboe wrote:
>> You can add your stuff for testing, ok no problem. You can put things in
>> plase so that I can test and profile potential changes. But you are
>> stepping on my toes by changing things I work on.
>>
>
> Let me take this oportunity to thank you for finding and reportin
> You can add your stuff for testing, ok no problem. You can put things in
> plase so that I can test and profile potential changes. But you are
> stepping on my toes by changing things I work on.
Let me take this oportunity to thank you for finding and reporting these bugs
in a productive manner
Øyvind Harboe wrote:
>> I maintain that the whole jtag_add_dr_scan_now and changing of
>> in_handler functionality must be reverted. Im am not sure about the
>> exact rev, Öyvind PLEASE, you are at the moment screwing up things for
>> other people without good cause.
>>
>> There might be a good id
On Thursday 07 May 2009, Martin Panter wrote:
> I never used git bisect so I don't know exactly how it works.
"git bisect --help" summarizes:
git bisect start
git bisect bad ... assuming current is broken
git bisect good revid ... some known-good version
Then
> I maintain that the whole jtag_add_dr_scan_now and changing of
> in_handler functionality must be reverted. Im am not sure about the
> exact rev, Öyvind PLEASE, you are at the moment screwing up things for
> other people without good cause.
>
> There might be a good idea there somwhere, but I am
Øyvind Harboe wrote:
> On Fri, May 8, 2009 at 2:18 AM, Magnus Lundin wrote:
>
>> Here is my last comment for tonight, promise :)
>>
>> Before we had a setup where it was possible to use inhandlers, or to not
>> use inhadlers and place the corresponding logic in the upper layer.
>>
>> Now inhand
On Thursday 07 May 2009, Zach Welch wrote:
> > > If this were using "git", I'd have done it already ... is the
> > > magic SVN command "svn switch -r REVISION"? At least there's
> > > only one development sequence, no branch merges to resolve. ;)
> >
> > svn will probably do this *MUCH* slower th
On Fri, May 8, 2009 at 2:18 AM, Magnus Lundin wrote:
> Here is my last comment for tonight, promise :)
>
> Before we had a setup where it was possible to use inhandlers, or to not
> use inhadlers and place the corresponding logic in the upper layer.
>
> Now inhandlers are supposed to be bad, it is
Zach Welch wrote:
> On Thu, 2009-05-07 at 20:26 +0200, Øyvind Harboe wrote:
>
>> On Thu, May 7, 2009 at 7:18 PM, David Brownell wrote:
>>
>>> On Thursday 07 May 2009, Øyvind Harboe wrote:
>>>
On Thu, May 7, 2009 at 6:38 PM, David Brownell wrote:
> One of the
On Thu, 2009-05-07 at 20:26 +0200, Øyvind Harboe wrote:
> On Thu, May 7, 2009 at 7:18 PM, David Brownell wrote:
> > On Thursday 07 May 2009, Øyvind Harboe wrote:
> >> On Thu, May 7, 2009 at 6:38 PM, David Brownell wrote:
> >> > One of the patches since the merge of the ti_dm355.cfg line-end
> >>
Martin Panter wrote:
> On 08/05/2009, David Brownell wrote:
>
>> On Thursday 07 May 2009, David Brownell wrote:
>> > http://search.cpan.org/~infinoid/App-SVN-Bisect-0.8/bin/svn-bisect
>>
>>
>> Well that was a waste of a few hours. It got into a mode
>> where it kept producing unbuildable tre
On 08/05/2009, David Brownell wrote:
> On Thursday 07 May 2009, David Brownell wrote:
> > http://search.cpan.org/~infinoid/App-SVN-Bisect-0.8/bin/svn-bisect
>
>
> Well that was a waste of a few hours. It got into a mode
> where it kept producing unbuildable trees, with refs to
> jtag_add_dr_sc
On Thursday 07 May 2009, David Brownell wrote:
> http://search.cpan.org/~infinoid/App-SVN-Bisect-0.8/bin/svn-bisect
Well that was a waste of a few hours. It got into a mode
where it kept producing unbuildable trees, with refs to
jtag_add_dr_scan_now() added in r1629 but not, so far as
a quick sca
I was wrong, there is one more comment :)
The problem with out of context in variables (a real problem, I agree,
but not what makes current code misbehave) has nothing to do with
in_handlers, it is really about the in_value field pointing to a
receiving value.
The inhandler simply transforms
Here is my last comment for tonight, promise :)
Before we had a setup where it was possible to use inhandlers, or to not
use inhadlers and place the corresponding logic in the upper layer.
Now inhandlers are supposed to be bad, it is dictated that inhandlers
are bad. I know about the potentioal
On Fri, May 8, 2009 at 1:55 AM, Magnus Lundin wrote:
>
> Did you look at jtag_add_dr_scan_now() implemenation?
>
> It calls jtag_execute_queue_noclear(), so we *can* use stack variables
> here for in_value.
>
>
>
> This is basically: jtag_add_dr_scan_now() == jtag_
Did you look at jtag_add_dr_scan_now() implemenation?
It calls jtag_execute_queue_noclear(), so we *can* use stack variables
here for in_value.
This is basically:jtag_add_dr_scan_now() == jtag_add_dr_scan +
jtag_execute_queue , we have that in the
Øyvind Harboe wrote:
> On Fri, May 8, 2009 at 1:18 AM, Magnus Lundin wrote:
>
>> Ųyvind Harboe wrote:
>>
The problem with the "fix" and the whole change set is that the
fields{1].in_value variable is not assigned any return value until after
jtag_execute_queue(), and that i
Øyvind Harboe wrote:
> On Fri, May 8, 2009 at 1:18 AM, Magnus Lundin wrote:
>
>> Ųyvind Harboe wrote:
>>
The problem with the "fix" and the whole change set is that the
fields{1].in_value variable is not assigned any return value until after
jtag_execute_queue(), and that i
On Fri, May 8, 2009 at 1:18 AM, Magnus Lundin wrote:
> Ųyvind Harboe wrote:
>>>
>>> The problem with the "fix" and the whole change set is that the
>>> fields{1].in_value variable is not assigned any return value until after
>>> jtag_execute_queue(), and that is long after we exit this function a
Øyvind Harboe wrote:
>> The problem with the "fix" and the whole change set is that the
>> fields{1].in_value variable is not assigned any return value until after
>> jtag_execute_queue(), and that is long after we exit this function and temp
>> is out of scope.
>>
>
> Did you look at jtag_ad
> The problem with the "fix" and the whole change set is that the
> fields{1].in_value variable is not assigned any return value until after
> jtag_execute_queue(), and that is long after we exit this function and temp
> is out of scope.
Did you look at jtag_add_dr_scan_now() implemenation?
It
Consider the simplifications you will have in 99% of all calling
code + the JTAG implementations.
The in_handler behaviour can be synthesized on top of the JTAG
API layer in various ways and if there is a performance problem,
then it will become more clear to the caller how to deal with this
(crea
Øyvind Harboe wrote:
> On Fri, May 8, 2009 at 12:25 AM, Magnus Lundin wrote:
>
>> The problem is that the inhandler is called asynchronosly from the jtag
>> layer when the indata has been received.
>> When jtag_add_dr_scan_now(2, fields, TAP_INVALID) is sent then we have
>> not even sent the j
Øyvind Harboe wrote:
> On Fri, May 8, 2009 at 12:25 AM, Magnus Lundin wrote:
>
>> The problem is that the inhandler is called asynchronosly from the jtag
>> layer when the indata has been received.
>> When jtag_add_dr_scan_now(2, fields, TAP_INVALID) is sent then we have
>> not even sent the j
On Fri, May 8, 2009 at 12:39 AM, Zach Welch wrote:
> Hi all,
>
> The file, src/helper/tclapi.c, is not used in-tree. Can we remove it?
It's in svn if we miss it... :-)
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
_
On Fri, May 8, 2009 at 12:25 AM, Magnus Lundin wrote:
> The problem is that the inhandler is called asynchronosly from the jtag
> layer when the indata has been received.
> When jtag_add_dr_scan_now(2, fields, TAP_INVALID) is sent then we have
> not even sent the jtag data to the target son the i
Hi all,
The file, src/helper/tclapi.c, is not used in-tree. Can we remove it?
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Thursday 07 May 2009, Øyvind Harboe wrote:
> >> Can you do a bisection to figure out which version broke you?
> >
> > If this were using "git", I'd have done it already ... is the
> > magic SVN command "svn switch -r REVISION"? At least there's
> > only one development sequence, no branch merge
The problem is that the inhandler is called asynchronosly from the jtag
layer when the indata has been received.
When jtag_add_dr_scan_now(2, fields, TAP_INVALID) is sent then we have
not even sent the jtag data to the target son the in value is not
available untail after the next jtag_execute_
On Thu, 2009-05-07 at 15:18 -0700, Rick Altherr wrote:
> On May 7, 2009, at 1:30 PM, Zach Welch wrote:
>
> > On Thu, 2009-05-07 at 21:27 +0200, Michael Fischer wrote:
> >> Hello List,
> >>
> >> the problem with r1621 can be solved if AC_PROG_CC_C99
> >> is removed from configure.in. In this cas we
On May 7, 2009, at 1:30 PM, Zach Welch wrote:
On Thu, 2009-05-07 at 21:27 +0200, Michael Fischer wrote:
Hello List,
the problem with r1621 can be solved if AC_PROG_CC_C99
is removed from configure.in. In this cas we have r1620.
But this is not solving the problem in the last version
r1649 if
This patch, from 1636 to 1637 breaks the cortx targets.
I am not sure why but I really think removing the inhandler
functionallity is NOT ready for production use yet. Better testining is
needed before changes like this.
Regards
Magnus
Øyvind Harboe wrote:
> Committed.
>
> ### Eclipse Workspa
On Thu, 2009-05-07 at 21:27 +0200, Michael Fischer wrote:
> Hello List,
>
> the problem with r1621 can be solved if AC_PROG_CC_C99
> is removed from configure.in. In this cas we have r1620.
>
> But this is not solving the problem in the last version
> r1649 if I remove AC_PROG_CC_C99 here too.
On May 7, 2009, at 12:27 PM, Michael Fischer wrote:
Hello List,
the problem with r1621 can be solved if AC_PROG_CC_C99
is removed from configure.in. In this cas we have r1620.
But this is not solving the problem in the last version
r1649 if I remove AC_PROG_CC_C99 here too.
Best regards,
Mi
In order to get rid of in_handler, I need to submit a series
of patches to remove jtag_set_check_value()
usage.
This is the first in this series. I won't be posting messages
for each of these changes, but I will be making individual
commits.
The individual commits will be useful to do a svn versi
Committed.
Minor refactoring in preparation of retiring more in_handler usage.
Index: C:/workspace/openocd/src/jtag/jtag.c
===
--- C:/workspace/openocd/src/jtag/jtag.c(revision 1651)
+++ C:/workspace/openocd/src/jtag/jtag.c
Hello List,
the problem with r1621 can be solved if AC_PROG_CC_C99
is removed from configure.in. In this cas we have r1620.
But this is not solving the problem in the last version
r1649 if I remove AC_PROG_CC_C99 here too.
Best regards,
Michael
___
O
Hello List,
the last version I could build on Mac OS X was 1620,
after this I got unresolved symbols from libflash.
A lot of cfi functions could not be found.
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.
On Thu, May 7, 2009 at 7:18 PM, David Brownell wrote:
> On Thursday 07 May 2009, Øyvind Harboe wrote:
>> On Thu, May 7, 2009 at 6:38 PM, David Brownell wrote:
>> > One of the patches since the merge of the ti_dm355.cfg line-end
>> > update seems to have broken some aspect of scan chain discovery.
On Thu, May 7, 2009 at 6:38 PM, David Brownell wrote:
> One of the patches since the merge of the ti_dm355.cfg line-end
> update seems to have broken some aspect of scan chain discovery.
> See the openocd server startup transcript below, with "scan_chain"
> command debug output. (FWIW, using with
On Thursday 07 May 2009, Magnus Lundin wrote:
> > Which suggested a potential workaround here: slow TCK down even
> > more. Sure enough, at 750 KHz the startup doesn't fail...
>
> Is it possible to increase the jtag speed after the inital scan chain
> identification has succeded at 750 khz?
To
On Thursday 07 May 2009, Øyvind Harboe wrote:
> On Thu, May 7, 2009 at 6:38 PM, David Brownell wrote:
> > One of the patches since the merge of the ti_dm355.cfg line-end
> > update seems to have broken some aspect of scan chain discovery.
> > See the openocd server startup transcript below, with "
David Brownell wrote:
> One of the patches since the merge of the ti_dm355.cfg line-end
> update seems to have broken some aspect of scan chain discovery.
> See the openocd server startup transcript below, with "scan_chain"
> command debug output. (FWIW, using with an Olimex ft2232 adapter.)
>
> T
If there was a performance regression due to the changes I made,
then that's a red herring and it's just a weird side effect of something
I broke.
On Thu, May 7, 2009 at 6:38 PM, David Brownell wrote:
> One of the patches since the merge of the ti_dm355.cfg line-end
> update seems to have broken
One of the patches since the merge of the ti_dm355.cfg line-end
update seems to have broken some aspect of scan chain discovery.
See the openocd server startup transcript below, with "scan_chain"
command debug output. (FWIW, using with an Olimex ft2232 adapter.)
The recent TAP changes forced a sl
Committed
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm926ejs.c
===
--- src/target/arm926ejs.c (revision 1611)
+++ src/target/arm926ejs.c (working copy)
@@ -137,55 +137,41 @@
fields[0].tap = jtag_
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/xscale.c
===
--- src/target/xscale.c (revision 1628)
+++ src/target/xscale.c (working copy)
@@ -225,7 +225,7 @@
field.num_bits = tap->ir_length;
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/etb.c
===
--- src/target/etb.c(revision 1611)
+++ src/target/etb.c(working copy)
@@ -70,12 +70,12 @@
field.num_bits = tap->ir_length;
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/embeddedice.c
===
--- src/target/embeddedice.c(revision 1611)
+++ src/target/embeddedice.c(working copy)
@@ -251,34 +251,34 @@
fields[0].tap = ice
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm9tdmi.c
===
--- src/target/arm9tdmi.c (revision 1643)
+++ src/target/arm9tdmi.c (working copy)
@@ -283,34 +283,25 @@
fields[0].tap = jtag_i
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm9tdmi.c
===
--- src/target/arm9tdmi.c (revision 1611)
+++ src/target/arm9tdmi.c (working copy)
@@ -128,32 +128,32 @@
fields[0].tap
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm966e.c
===
--- src/target/arm966e.c(revision 1611)
+++ src/target/arm966e.c(working copy)
@@ -187,39 +187,30 @@
fields[0].tap = jtag_in
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm920t.c
===
--- src/target/arm920t.c(revision 1611)
+++ src/target/arm920t.c(working copy)
@@ -113,51 +113,37 @@
fields[0].tap = jtag_i
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm720t.c
===
--- src/target/arm720t.c(revision 1611)
+++ src/target/arm720t.c(working copy)
@@ -112,31 +112,24 @@
fields[0].tap = jtag_in
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm11_dbgtap.c
===
--- src/target/arm11_dbgtap.c (revision 1608)
+++ src/target/arm11_dbgtap.c (working copy)
@@ -130,7 +130,7 @@
* arm11_add_debug_SCAN_N(
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm_adi_v5.c
===
--- src/target/arm_adi_v5.c (revision 1628)
+++ src/target/arm_adi_v5.c (working copy)
@@ -77,22 +77,22 @@
fields[0].num_bits = 3
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/pld/virtex2.c
===
--- src/pld/virtex2.c (revision 1611)
+++ src/pld/virtex2.c (working copy)
@@ -98,12 +98,6 @@
return ERROR_OK;
}
-int virtex2_jtag_buf_to
On Thu, May 7, 2009 at 11:37 AM, David Brownell wrote:
> On Thursday 07 May 2009, Ųyvind Harboe wrote:
>> Committed.
>
> Hmm, but with DOS line ends (CRLF) ... is that
> why folk are sending patches as attachments??
Fixed.
set eol:style native
--
Øyvind Harboe
Embedded software and hardware
On Thursday 07 May 2009, Øyvind Harboe wrote:
> Committed.
Hmm, but with DOS line ends (CRLF) ... is that
why folk are sending patches as attachments??
Thanks for merging that.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
Get rid of some compile warnings if the oocd trace is included:
the bytes_read is a size_t.
--- src/target/oocd_trace.c (revision 1625)
+++ src/target/oocd_trace.c (working copy)
@@ -98,7 +98,7 @@
if ((bytes_read = read(oocd_trace->tty_fd,
((
On Thu, 2009-05-07 at 08:59 +0200, Øyvind Harboe wrote:
> I've deleted an old flash driver (at91sam7_old). Your build will fail
> unless you run bootstrap.
... unless you are using --enable-maintainer-mode. If you are, make
should detect the changed Makefile.am and will rebuild the associated
Mak
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
Basic SoC configuration for TI DaVinci DM355 chips. No declarations
or utilities for things you need during board bringup or debricking:
setting up PLLs, enabling clocks, configuring memory controllers, or
programing NANDs using 1-bit or 4-bit HW ECC. Yet...
---
src/target/target/ti_dm355.cfg |
I've deleted an old flash driver (at91sam7_old). Your build will fail
unless you run bootstrap.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@list
66 matches
Mail list logo
