Re: [Openocd-development] SVF to XSVF Converter, and Patches

On Dec 12, 2008, at 10:11 AM, Spencer Oliver wrote: As far as I can tell, there is no established standard. I would love to institute one. There was a basic standard, it seems to have vanished from the README basically follow the format of the existing source, use tabs not spaces. we wi

Re: [Openocd-development] Repository notes

On Dec 12, 2008, at 9:01 AM, Rick Altherr wrote: Later today I am going to move things around such that the repository has the following layout: trunk/ tags/ branches/ zy1000/ trunk/ tags/ branches/ This has been committed. I also cleaned out obsolete branches. -- Rick Altherr kc8...@k

Re: [Openocd-development] SVF to XSVF Converter, and Patches

> As far as the tabs/spaces issue, have you looked at the unix utility > "astyle"? I believe that's one of it's purposes. Also, might specify > a coding style that astyle supports, then one can just kick things > thru astyle, and voila, uniformity! I meant for oocd sources (C/C++); I don't know

Re: [Openocd-development] SVF to XSVF Converter, and Patches

> I am one of two main active developers of Kicad. For that project I put > in a standard configuration file for the very fine beautifier called > "uncrustify". So basically uncrustify settles the issue for us over > there. That is C++ and it is setup for spaces, but uncrustify will > handle bot

Re: [Openocd-development] SVF to XSVF Converter, and Patches

Dick Hollenbeck wrote: > Also, be aware that most python programs use spaces, not tabs for > indentation. This is also something I found nice. Tabs are a nuisance > and have out lived their day in my opinion. Perhaps the tap/space thing is being mis-understood. The formatting rules - are ge

Re: [Openocd-development] SVF to XSVF Converter, and Patches

Øyvind Harboe wrote: >> 3) Do you want the SVF to XSVF converter as part of this project, say in >> a separate directory? I also have an XSVF file dumper to show the >> contents of the XSVF file, also written in python. >> > > There is a contrib directory which contains code that runs on the

Re: [Openocd-development] [PATCH] fix (sometimes) non-working Cortex-M3breakpoints

> This is my first patch, so please let me know if I did > anything wrong. > The problem: for Cortex-M3 targets, the FPB unit (Flash Patch and > Breakpoint) was enabled only on reset event. If I connected > to already running code after it's been reset and tried to > set some breakpoints, Op

Re: [Openocd-development] [PATCH] enum tap_state spellings and clarifications

On Dec 12, 2008, at 11:18 AM, Dick Hollenbeck wrote: Rick Altherr wrote: Can you send the diff as an attachment rather than in the email body? That avoids whitespace changes introduced by various email clients. -- Rick Altherr kc8...@kc8apf.net Rick, I just downloaded the patch I se

Re: [Openocd-development] [PATCH] enum tap_state spellings and clarifications

Rick Altherr wrote: > > > Can you send the diff as an attachment rather than in the email body? > That avoids whitespace changes introduced by various email clients. > > -- > Rick Altherr > kc8...@kc8apf.net Rick, I just downloaded the patch I sent from here: https://lists.berlios.de/pipermail

Re: [Openocd-development] Repository notes

On Dec 12, 2008, at 10:34 AM, Øyvind Harboe wrote: I'm not enamored of having the zy1000 contents in the repo, but there is no technical reason it must leave. I would like Øyvind to consider moving the zy1000 contents to a separate repository at some future date. In terms of collaborati

Re: [Openocd-development] Repository notes

On Fri, Dec 12, 2008 at 6:01 PM, Rick Altherr wrote: > > On Dec 12, 2008, at 1:18 AM, Spencer Oliver wrote: > >> >>> Any other opinions on this? Has BerliOS responded? >>> >>> Rick >>> >> >> As yet all is quiet, but then berlios are never quick to respond. >> I cannot see this changing however, s

Re: [Openocd-development] [PATCH] enum tap_state spellings and clarifications

On Dec 12, 2008, at 10:16 AM, Dick Hollenbeck wrote: Rick, Here is the enum tap_state patch. For *global search and replace* like this, JEdit works great, seems to have handled tabs ok. When *manual editing* in tab mode, there are problems. Thanks, Dick Can you send the diff as an a

Re: [Openocd-development] PXA271 + strataflash bug

What OS, host architecture, and JTAG interface are you using? The GDB keep alive packet messages tend to show up when using GPIO-based JTAG interfaces that have delays after a write to deal with synchronization issues between host and target. Do your JTAG interface and target support RTCK

Re: [Openocd-development] SVF to XSVF Converter, and Patches

> 3) Do you want the SVF to XSVF converter as part of this project, say in > a separate directory? I also have an XSVF file dumper to show the > contents of the XSVF file, also written in python. There is a contrib directory which contains code that runs on the developer host PC. Could go there.

Re: [Openocd-development] SVF to XSVF Converter, and Patches

> > > > As far as I can tell, there is no established standard. I > would love > > to institute one. > > > > There was a basic standard, it seems to have vanished from the README > > basically follow the format of the existing source, use tabs > not spaces. > we will have to clarify a spec

Re: [Openocd-development] PXA271 + strataflash bug

Hi Rick I'm sorry to have disappeared, I had a bunch of lessons and exams to give so i didn't have time to work on this. good news and bad news: the complete program crash has stopped with the latest svn, however the gdb keep alive packet errors are still there. so in the meantime: I'm actually g

Re: [Openocd-development] SVF to XSVF Converter, and Patches

> > As far as I can tell, there is no established standard. I > would love to institute one. > There was a basic standard, it seems to have vanished from the README basically follow the format of the existing source, use tabs not spaces. we will have to clarify a spec if we cannot find the ol

Re: [Openocd-development] Repository notes

On Dec 12, 2008, at 1:18 AM, Spencer Oliver wrote: Any other opinions on this? Has BerliOS responded? Rick As yet all is quiet, but then berlios are never quick to respond. I cannot see this changing however, searching through old requests we are not the first to ask. so this leaves

Re: [Openocd-development] SVF to XSVF Converter, and Patches

On Dec 12, 2008, at 8:51 AM, Dick Hollenbeck wrote: Hello, Please let me introduce myself. I am an embedded developer of 25 years. Software is my thing. I wrote an SVF to XSVF converter in python and it is at a point where it needs testing. While I am doing that I am improving the di

Re: [Openocd-development] [PATCH] fix (sometimes) non-working Cortex-M3breakpoints

> > This is my first patch, so please let me know if I did > anything wrong. > The problem: for Cortex-M3 targets, the FPB unit (Flash Patch and > Breakpoint) was enabled only on reset event. If I connected > to already running code after it's been reset and tried to > set some breakpoints,

[Openocd-development] SVF to XSVF Converter, and Patches

Hello, Please let me introduce myself. I am an embedded developer of 25 years. Software is my thing. I wrote an SVF to XSVF converter in python and it is at a point where it needs testing. While I am doing that I am improving the diagnostics in your xsvf.c. Questions: 1) How do you r

[Openocd-development] [PATCH]remove specific variant

Hi, The attached patch removes core specific variant field and uses the target->variant for all checks. seemed a bit of a waste to have two fields doing the same thing. No objection and i will commit. Cheers Spen target_variant.patch Description: Binary data ___

[Openocd-development] [PATCH] fix (sometimes) non-working Cortex-M3 breakpoints

Hello All, This is my first patch, so please let me know if I did anything wrong. The problem: for Cortex-M3 targets, the FPB unit (Flash Patch and Breakpoint) was enabled only on reset event. If I connected to already running code after it's been reset and tried to set some breakpoints, OpenO

[Openocd-development] Repository notes

It doesn't affect me for sure, but it affect the OpenOCD project itself. We have to keep OpenOCD as clean as possible in an understandable structure. Adding inside the OpenOCD repository some proprietary projects based on OpenOCD, or OS related stuff, is really not the good way to go. The Ope

[Openocd-development] [PATCH]gdb pipes

Hi, Find attached a patch (1st part) that enables openocd to talk to gdb using pipes (stdin, stdout) rather than sockets. It has been lying around my pc for about 6 months, thought it was about time to get it into trunk. It is enabled using the new cmd line option --pipe or -p currently tested on

Re: [Openocd-development] Repository notes

Please describe what problem you are experiencing. The ZY1000 is used for collaboration between some OpenOCD developers, much like a development branch. It shouldn't affect you in any way. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash progra

[Openocd-development] Repository notes

Please remove the Zy1000 and any eCos related files in the OpenOCD project. These are two different projects. zy1000 inside openocd ??? Why ! gdb-arm-cygwin-6.7.zip under zy1000 ??? Why ! The OpenOCD no

Re: [Openocd-development] Altear Nios support

> Do docs which are GPL friendly exist? > > Any source code out there? > > (I know the OpenOCD bits, but not Altera Nios). > > -- Lat time i looked the jtag part is undisclosed. I have heard some people use the system console, as this gives access to various core functions. http://nioswiki.jot

Re: [Openocd-development] Repository notes

Please do nothing for now. The zy1000 directory is used for collaboration that *DOES* result in stuff being ported over to OpenOCD trunk. There are no observable problems here for other developers or usres and it saves a bunch of time leaving things as is. Think about it as a development branch

Re: [Openocd-development] Repository notes

> Any other opinions on this? Has BerliOS responded? > > Rick > As yet all is quiet, but then berlios are never quick to respond. I cannot see this changing however, searching through old requests we are not the first to ask. so this leaves us with what layout to use, we have to make sure the