Re: [Openocd-development] [PULL REQUEST] dsp5680xx fix - halt, flash lock-unlock procedures

I think patches are best for review, but pulling is easier for these sort of series for the maintainer. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___

Re: [Openocd-development] Coding style plan

On Wed, Aug 31, 2011 at 12:21 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 11:26 Tue 30 Aug     , Øyvind Harboe wrote: >> Goal: switch OpenOCD to use the Kernel coding style >> >> Plan: >> >> a) get all outstanding patches merged >> b) do wholesale automated(hopefully) code style fix >> d) pat

Re: [Openocd-development] [PULL REQUEST] dsp5680xx fix - halt, flash lock-unlock procedures

i tried to put reasonable info into commits any questions and/or feedback is welcome regards, -- Rodrigo. 0001-dsp568013-disable-polling-by-default.patch Description: Binary data 0002-def-syntax-to-match-tap-irlen.patch Description: Binary data 0003-optional-crc-for-flash-writing.patch Desc

[Openocd-development] [PULL REQUEST] dsp5680xx fix - halt, flash lock-unlock procedures

are available in the git repository at: git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry Rodrigo L. Rosa (8): dsp568013 disable polling by default def syntax to match tap irlen optional crc for flash writing fix error handling during halt fix debug mode,lock

Re: [Openocd-development] [PULL REQUEST] dsp5680xx fix - halt, flash lock-unlock procedures

i accidentally changed some stuff when cleaning up for this request. please do not pull it. i'll fix and ask again, and attach the corresponding patches, so it's easy to merge and to review. thanks, and sorry for the complications. On Tue, Aug 30, 2011 at 4:14 PM, Andreas Fritiofson wrote: > Did

Re: [Openocd-development] GDB notification of processor reset

On Sat, Aug 27, 2011 at 12:43 AM, Evan Hunter wrote: > Hi All, > > ** ** > > I've noticed that if my processor gets reset whilst debugging a program, > GDB knows nothing about it. I would have thought GDB should stop, in a > similar way as hitting a breakpoint. > > ** ** > > Is there curr

Re: [Openocd-development] [PULL Request] Flash program speedup through asynchronous algorithms

On Tue, Aug 16, 2011 at 8:40 AM, Simon Barner wrote: > On 16.08.2011 01:25, Andreas Fritiofson wrote: > > > > > > On Wed, Aug 10, 2011 at 12:01 AM, Spencer Oliver > > wrote: > > > > On 09/08/2011 22:15, Øyvind Harboe wrote: > > > > Any objections? > > > >

Re: [Openocd-development] [PULL REQUEST] dsp5680xx fix - halt, flash lock-unlock procedures

Did we decide whether patches should be posted to the list, in addition to the pull request, to ease reviews? Personally I much rather check the patches via a web interface, if one is available for the repo. On the other hand, having the patches in the list archive could be good (if they're not imm

Re: [Openocd-development] [PATCH]style: typedefs are evil

On Tue, Aug 30, 2011 at 9:25 PM, Eric Wetzel wrote: > On the discussion of style, I mentioned that the Linux coding standard > doesn't really like typedefs. Here is an article from Greg K-H that > partially addresses the subject: > http://www.linuxjournal.com/article/5780?page=0,2 > > I don't rea

Re: [Openocd-development] Coding style plan

On 11:26 Tue 30 Aug , Øyvind Harboe wrote: > Goal: switch OpenOCD to use the Kernel coding style > > Plan: > > a) get all outstanding patches merged > b) do wholesale automated(hopefully) code style fix > d) patch w/documentation and scripts to enforce the new coding style. > > Resources: >

Re: [Openocd-development] [PATCH]style: typedefs are evil

On Wed, Aug 31, 2011 at 12:27 AM, Martin Schmölzer < martin.schmoel...@student.tuwien.ac.at> wrote: > Hi, > > On Tue, 2011-08-30 at 15:25 -0400, Eric Wetzel wrote: > > I don't think I have a way to verify the changes I made to > > src/flash/ocl/at91sam7x (from the second patch) or the changes I wo

Re: [Openocd-development] [PATCH]style: typedefs are evil

Hi, On Tue, 2011-08-30 at 15:25 -0400, Eric Wetzel wrote: > On the discussion of style, I mentioned that the Linux coding standard > doesn't really like typedefs. Here is an article from Greg K-H that > partially addresses the subject: > http://www.linuxjournal.com/article/5780?page=0,2 > > I don

[Openocd-development] [PULL REQUEST] dsp5680xx fix - halt, flash lock-unlock procedures

are available in the git repository at: git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry The following changes since commit 67bb8a6cb208a7529045fc11b1dc30adf98d928f: Rodrigo L. Rosa (1): dsp568013 disable polling by default are available in the git repository at: git://repo

Re: [Openocd-development] [PATCH]style: typedefs are evil

I think this is the right direction, but I'd like to see the patches split up and verified that there is more than just some silly renaming going on... -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ _

[Openocd-development] [PATCH]style: typedefs are evil

On the discussion of style, I mentioned that the Linux coding standard doesn't really like typedefs. Here is an article from Greg K-H that partially addresses the subject: http://www.linuxjournal.com/article/5780?page=0,2 I don't really like typedefs either, so I started writing a script called 'd

Re: [Openocd-development] vsllink driver compile fails with'vsllink_debug_buffer' defined but not used

OK. Thanks. simonqian.openocd via foxmail Sender: Eric Wetzel Date: 2011年8月30日(星期二) 下午9:52 To: openocd-development Subject: [Openocd-development] vsllink driver compile fails with'vsllink_debug_buffer' defined but not used vsllink.c defines the 'vsllink_debug_buffer' function when verbose USB

Re: [Openocd-development] vsllink driver compile fails with'vsllink_debug_buffer' defined but not used

USB communication is handled by code under versaloon directory. So _DEBUG_USB_COMMS_ should not be used in vsllink.c. Attachment is the patch. simonqian.openocd via foxmail 发件人： Øyvind Harboe 发送时间： 2011年8月31日(星期三) 上午12:36 收件人： Eric Wetzel 抄送： openocd-development 主题： Re: [Openocd-development]

Re: [Openocd-development] [patch] ARM-JTAG-EW fixes 1/2

Any objections? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.be

Re: [Openocd-development] [PATCH] Improvements to Keil ULINK driver

Any objections? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.be

Re: [Openocd-development] vsllink driver compile fails with 'vsllink_debug_buffer' defined but not used

Any objections? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.ber

Re: [Openocd-development] [PATCH] Cortex_A context & hybrid breakpoints

Merged. Thanks! Fixed: ex_a.c -o cortex_a.o cc1: warnings being treated as errors cortex_a.c: In function ‘cortex_a8_add_hybrid_breakpoint’: cortex_a.c:1481:6: error: ‘retval’ may be used uninitialized in this function Also joined the two commits as the first one didn't build. Did you do an in

Re: [Openocd-development] Coding style plan

On Tue, Aug 30, 2011 at 5:26 AM, Øyvind Harboe wrote: > Goal: switch OpenOCD to use the Kernel coding style > > Plan: > > a) get all outstanding patches merged > b) do wholesale automated(hopefully) code style fix > d) patch w/documentation and scripts to enforce the new coding style. > > Resource

[Openocd-development] vsllink driver compile fails with 'vsllink_debug_buffer' defined but not used

vsllink.c defines the 'vsllink_debug_buffer' function when verbose USB comms or verbose JTAG comms are enabled, but each use is guarded by #ifdef _DEBUG_JTAG_IO. So the function is unused if only verbose USB comms are enabled, and this is an error with -Werror. I fixed the problem as described in t

[Openocd-development] Coding style plan

Goal: switch OpenOCD to use the Kernel coding style Plan: a) get all outstanding patches merged b) do wholesale automated(hopefully) code style fix d) patch w/documentation and scripts to enforce the new coding style. Resources: Does anyone want to do this? -- Øyvind Harboe - Can Zylin Consul

Re: [Openocd-development] Errors encountered programming an FPGA using 13MB SVF file

On 27/08/11 17:38, Tomek CEDRO wrote: On Sat, Aug 27, 2011 at 3:40 PM, Uwe Bonnes wrote: while not a cure for your openocd problem, what about xc3sprog? svn co https://xc3sprog.svn.sourceforge.net/svnroot/xc3sprog xc3sprog It is. I am using Xilinx FPGA right now and xc3sprog is great tool to

Re: [Openocd-development] Coding style

> Do not fear :) This is what the Linux Documentation/CodingStyle says: > > "Encoding the type of a function into the name (so-called Hungarian > notation) is brain damaged - the compiler knows the types anyway and can > check those, and it only confuses the programmer.  No wonder MicroSoft > makes

Re: [Openocd-development] Coding style

On Tue, Aug 30, 2011 at 6:53 AM, Øyvind Harboe wrote: > If Kernel programming guidelines requires variable names like that, > then I don't want to see it for OpenOCD. Do not fear :) This is what the Linux Documentation/CodingStyle says: "Encoding the type of a function into the name (so-called Hu