Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

Magnus Lundin wrote: > Øyvind Harboe wrote: > >>> I have found it to, IR in bypass returns 0x01 if I recall correctly, so >>> bypass taps should not be checked, or checked with a correct value. >>> >>> The flag used to signal no IR check was to set in_handler = NULL;/* >>> disable verificat

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

Øyvind Harboe wrote: >> I have found it to, IR in bypass returns 0x01 if I recall correctly, so >> bypass taps should not be checked, or checked with a correct value. >> >> The flag used to signal no IR check was to set in_handler = NULL;/* >> disable verification by default */ >> >> Really ug

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

> A closer look, for configured taps not in the list  of taps used in the > scan_field array passed to the function the default values should be > >        scan_size = tap->ir_length; >        (*last_cmd)->cmd.scan->fields[nth_tap].tap = tap; >        (*last_cmd)->cmd.scan->fields[nth_tap].num_bits

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

Øyvind Harboe wrote: >> add_ir_scan is called with just 1 scan_field, then this function sets the >> number of scanfields equal to the number of taps without allocating a a >> larger scan_field array. >> The error will be seen depending on if the out of bounds memory is cleared >> to 0 or not. >>

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

> add_ir_scan is called with just 1 scan_field, then this function sets the > number of scanfields equal to the number of taps without allocating a a > larger scan_field array. > The error will be seen depending on if the out of bounds memory is cleared > to 0 or not. Hmm I didn't change the p

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

Hmmm Is it conceivable that there is some problem that was lurking in jlink that is now hitting you? the bitbang driver does produces the expected error message in 1672 and works in 1674 jlink crashes in 1672. cmd->fields[i].in_value == NULL in your case from the jtag_read_buffer() call

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

It is head, rev 1672 The first idscan succeds, but the IR check fails Debug output is: Starting program: /home/lundin/delad/arbete/mikrop/arm/openocd/trunk/src/openocd Open On-Chip Debugger 0.2.0-in-development (2009-05-08-12:06) svn:1672M BUGS? Read http:/

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

On Fri, 2009-05-08 at 09:43 +0200, Øyvind Harboe wrote: > On Fri, May 8, 2009 at 9:40 AM, Zach Welch wrote: > > On Fri, 2009-05-08 at 09:33 +0200, Øyvind Harboe wrote: > > [snip] > >> I have to give a bit of thought on how to best to profile this, i.e. to > >> find the precise location of the culp

[Openocd-development] in_handler: w/o "in_value", mismatch in SIR

> > On Fri, May 8, 2009 at 10:28 AM, Magnus Lundin > wrote: > >/ Ųyvind Harboe wrote: > />>>/ > />>>/ Stop trading USB performance for Zylin performance, stop changing the > />>>/ JTAG > />>>/ API, improving the implementation is nice

[Openocd-development] in_handler: w/o "in_value", mismatch in SIR

> >/ Stop trading USB performance for Zylin performance, stop changing the JTAG > />/ API, improving the implementation is nice though. > />/ Listen to Laurent this time, he is right !! > / > This is a red herring. I do *NOT* intend to trade USB performance for > zylin performance. > > I'm doing th

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

On Fri, May 8, 2009 at 10:28 AM, Magnus Lundin wrote: > Ųyvind Harboe wrote: >>> >>> Stop trading USB performance for Zylin performance, stop changing the >>> JTAG >>> API, improving the implementation is nice though. >>> Listen to Laurent this time, he is right !! >>> >> >> This is a red herring.

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

Øyvind Harboe wrote: >> Stop trading USB performance for Zylin performance, stop changing the JTAG >> API, improving the implementation is nice though. >> Listen to Laurent this time, he is right !! >> > > This is a red herring. I do *NOT* intend to trade USB performance for > zylin performanc

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

On Friday 08 May 2009, Øyvind Harboe wrote: > If someone has a bug/regression that comes first though. FYI I'm having a hard time reproducing the specific failures I reported before. I'm not sure what's going on. The 1.5 MHz rate seems to work, 750 KHz not needed. And the 3 MHz isn't working ev

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

> Stop trading USB performance for Zylin performance, stop changing the JTAG > API, improving the implementation is nice though. > Listen to Laurent this time, he is right !! This is a red herring. I do *NOT* intend to trade USB performance for zylin performance. I'm doing this for a couple of re

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

Øyvind Harboe wrote: > On Fri, May 8, 2009 at 9:53 AM, Magnus Lundin wrote: > >> Ųyvind Harboe wrote: >> >>> On Fri, May 8, 2009 at 9:40 AM, Zach Welch wrote: >>> >>> On Fri, 2009-05-08 at 09:33 +0200, Ųyvind Harboe wrote: [snip] > I have to give a

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

On Fri, May 8, 2009 at 9:53 AM, Magnus Lundin wrote: > Ųyvind Harboe wrote: >> >> On Fri, May 8, 2009 at 9:40 AM, Zach Welch wrote: >> >>> >>> On Fri, 2009-05-08 at 09:33 +0200, Ųyvind Harboe wrote: >>> [snip] >>> I have to give a bit of thought on how to best to profile this, i.e. to >

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

Øyvind Harboe wrote: > On Fri, May 8, 2009 at 9:40 AM, Zach Welch wrote: > >> On Fri, 2009-05-08 at 09:33 +0200, Øyvind Harboe wrote: >> [snip] >> >>> I have to give a bit of thought on how to best to profile this, i.e. to >>> find the precise location of the culprit. >>> >>> Any ideas? >>

[Openocd-development] in_handler: w/o "in_value", mismatch in SIR

> 2009/5/8 Magnus Lundin >: > >/ The situation is very different on embedded host with a bitbang connection > />/ to the target versus PC+USB, or PC + simple ethernet JTAG. > />/ > />/ Here are the numbers from the Swedish jury: > />/

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

On Fri, May 8, 2009 at 9:40 AM, Zach Welch wrote: > On Fri, 2009-05-08 at 09:33 +0200, Øyvind Harboe wrote: > [snip] >> I have to give a bit of thought on how to best to profile this, i.e. to >> find the precise location of the culprit. >> >> Any ideas? > > I have had success with oprofile.  This

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

On Fri, 2009-05-08 at 09:33 +0200, Øyvind Harboe wrote: [snip] > I have to give a bit of thought on how to best to profile this, i.e. to > find the precise location of the culprit. > > Any ideas? I have had success with oprofile. This would give you what you need. --Z __

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

2009/5/8 Magnus Lundin : > The situation is very different on embedded host with a bitbang connection > to the target versus PC+USB, or PC + simple ethernet JTAG. > > Here are the numbers from the Swedish jury: > > Measured with the debug millsecond time output. > STM32 + JLink adapter, Linux on At

[Openocd-development] in_handler: w/o "in_value", mismatch in SIR

> On Fri, May 8, 2009 at 8:53 AM, Magnus Lundin > wrote: > >/ U;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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

The situation is very different on embedded host with a bitbang connection to the target versus PC+USB, or PC + simple ethernet JTAG. Here are the numbers from the Swedish jury: Measured with the debug millsecond time output. STM32 + JLink adapter, Linux on Athlon dual core 2.4 GHz. Every test d

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

Ø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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

> 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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

Ø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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

> 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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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 > >>

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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.

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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 "

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

Re: [Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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

[Openocd-development] in_handler: w/o "in_value", mismatch in SIR

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