Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread David Brownell
> I guess we have very different approaches to looking at new software. > Since the structures (classes) are the skeleton There's a book titled something like "structs + methods = programs". :) When I'm analysing code to see how it works inside, I consider it a flaw if I can't look through the

Re: [Openocd-development] [patch 0/5] header cleanups

2009-11-15 Thread Zach Welch
On Sun, 2009-11-15 at 13:38 -0700, David Brownell wrote: > The nest of header inclusions is something of a mess; touch > one, and totally unrelated code will "need" to be recompiled. > > So here are a few patches making that a bit better for the > headers in the "target" part of the tree. In orde

Re: [Openocd-development] [PATCH 08/11] improve buf_cpy helper

2009-11-15 Thread Zach Welch
On Sun, 2009-11-15 at 16:12 -0700, David Brownell wrote: > On Sunday 15 November 2009, Zach Welch wrote: > > > > > > Or maybe I was. Given that it copies everything, why > > > is there code *after* the copy mangling the last byte? > > > Wouldn't that only be correct when the code copied > > > all

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread Michael Bruck
On Sun, Nov 15, 2009 at 23:00, David Brownell wrote: > [ offtopic threads #2, #3, ... ] > >> The reason why I did not plug arm11 into the existing arm >> infrastructure and why we implemented etm as a tcl script > > "We" didn't see any such Tcl scripts posted though. Yes, they are tailored to our

Re: [Openocd-development] [PATCH 08/11] improve buf_cpy helper

2009-11-15 Thread David Brownell
On Sunday 15 November 2009, Zach Welch wrote: > > > > Or maybe I was.  Given that it copies everything, why > > is there code *after* the copy mangling the last byte? > > Wouldn't that only be correct when the code copied > > all but the trailing partial byte? > > It masks the last byte, ensuring

Re: [Openocd-development] [PATCH 08/11] improve buf_cpy helper

2009-11-15 Thread David Brownell
On Sunday 15 November 2009, Zach Welch wrote: > > > > I'd be happier if it were called DIV_ROUND_UP() like a > > certain OS kernel I could mention ... not as cryptic. > > I agree that the current name stands to be improved. > > > (Likewise, there's a DIM which is used for ARRAY_SIZE. > > And lot

Re: [Openocd-development] Tiny jtag_add_xxxx cleanup in etb.c

2009-11-15 Thread Øyvind Harboe
I quickly typed up something, it wasn't a patch and it was full of bugs. Oh, and it doesn't compile. :-) I was just pointing a finger at how the code can be made much simpler. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _

Re: [Openocd-development] Tiny jtag_add_xxxx cleanup in etb.c

2009-11-15 Thread David Brownell
On Sunday 15 November 2009, Øyvind Harboe wrote: > @@ -202,13 +202,13 @@ static int etb_read_ram(etb_t *etb, uint32_t *data, > int num_frames) for (i = 0; i < num_frames; i++) > { > /* ensure nR/W reamins set to read */ > - buf_set_u32(fields[2].out_value, 0, 1, 0);

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread Michael Bruck
On Sun, Nov 15, 2009 at 22:16, David Brownell wrote: > [ Offtopic thread #1:  "struct typedefs considered harmful" ] > >> struct foo >> >> and >> >> foo_t >> >> are both universally understood. > > I can't know what a "foo_t" is without looking it up, > so it's not "universal" in any meaningful se

Re: [Openocd-development] SWD, Simon's branch and git.

2009-11-15 Thread Andrew Rogers
I had some success by doing: $ git clone http://repo.or.cz/r/openocd/simonqian.git $ cd simonqian/ $ git pull http://repo.or.cz/r/openocd/simonqian.git sq/swj_versaloon Regards Andrew On Sun, 2009-11-15 at 21:31 +, Andrew Rogers wrote: > I've recently seen some of the work Simon has done wi

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread David Brownell
[ Offtopic thread #1: "struct typedefs considered harmful" ] > struct foo > > and > > foo_t > > are both universally understood. I can't know what a "foo_t" is without looking it up, so it's not "universal" in any meaningful sense. > "struct foo" however clutters the > code, especially in

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread David Brownell
[ offtopic threads #2, #3, ... ] > The reason why I did not plug arm11 into the existing arm > infrastructure and why we implemented etm as a tcl script "We" didn't see any such Tcl scripts posted though. "We" want to see ETM support that doesn't need to be rewritten from scratch for each new co

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread David Brownell
[ *ON* topic thread ] > Your patch is purely about enforcing arbitrary syntax rules and in the > process adding redundant code that obscures what is going on. For > example consider: > > ... > ARM11_HANDLER(bar), > GENERIC_ARM_HANDLER(dog), > ARM11_HANDLER(moo), > ... See, I count those *_HANDLE

[Openocd-development] Tiny jtag_add_xxxx cleanup in etb.c

2009-11-15 Thread Øyvind Harboe
The fact that this malloc(1) has survived the latest purges just goes to show how obtuse the jtag_add_xxx() code is. Also, this patch is interesting because it shows how switching to a 32 bit word size rather than 8 bit, would make the code a lot less obtuse. In this case 8 bit happens to be suff

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread Øyvind Harboe
> Take for example: > > fields[0].tap = etm_reg->jtag_info->tap; > fields[0].num_bits = 32; > fields[0].out_value = reg->value; > fields[0].in_value = NULL; > fields[0].check_value = NULL; > fields[0].check_mask = NULL; > > fields[1].tap = etm_reg->jtag_info->tap; > fields[1].num_bits = 7; > fields

[Openocd-development] SWD, Simon's branch and git.

2009-11-15 Thread Andrew Rogers
I've recently seen some of the work Simon has done with SWD and I think that it overlaps with what I am doing. I had, until now, missed Simon's post on the 7th November 2009 and some earlier posts. I can't seem to get Simon's branch cloned properly. Here's what I'm doing: $ git clone http://repo.

[Openocd-development] [patch 5/5] #include "target.h" less wildly

2009-11-15 Thread David Brownell
Don't include "target.h" from more headers than necessary. This avoids needless interdependencies and duplicated include paths. Don't needlessly include it in source files, either. --- src/ecosboard.c |1 - src/flash/at91sam3.c|1 - src/flash/lpc3180_n

[Openocd-development] [patch 4/5] target: no implicit #includes of "register.h"

2009-11-15 Thread David Brownell
Same deal: "register.h" got needlessly included all over the place because of being in a few widely included headers. So take it out of the header files which included it, and put it in files which use it ... reduce needless interdependencies. Also, don't need that extra "types.h" inclusion. ---

[Openocd-development] [patch 3/5] target: less implicit inclusion of "command.h"

2009-11-15 Thread David Brownell
Lots of files still include it, often through needless duplicate inclusion of "log.h"; sigh. This cleans up the inclusion graph a bunch, so there are fewer inclusion paths, but it doesn't change much otherwise. --- src/ecosboard.c|3 --- src/flash/at91sam3.c |1 - src/he

[Openocd-development] [patch 0/5] header cleanups

2009-11-15 Thread David Brownell
The nest of header inclusions is something of a mess; touch one, and totally unrelated code will "need" to be recompiled. So here are a few patches making that a bit better for the headers in the "target" part of the tree. In order: - breakpoint.h - algorithm.h - command.h - register.h

[Openocd-development] [patch 1/5] target: don't implicitly include "breakpoint.h"

2009-11-15 Thread David Brownell
Most files in the tree seem to have ended up including this, and *quite* needlessly ... only code implementing or using breakpoints actually needs these declarations. So take it out of the header files which included it, and put it in files which use it ... reduce needless interdependencies. ---

[Openocd-development] [patch 2/5] target: don't implicitly include "algorithm.h"

2009-11-15 Thread David Brownell
Most files in the tree seem to have ended up including this, and *quite* needlessly ... only code implementing or using downloadable algorithms actually needs these declarations. So take it out of the header files which included it, and put it in files which use it ... reduce needless interdepende

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread Michael Bruck
On Sun, Nov 15, 2009 at 19:13, David Brownell wrote: > On Sunday 15 November 2009, Michael Bruck wrote: >> >>> The macro is right above the table. > > Yep.  At least, *now* it's right above. This is the original commit: http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f

Re: [Openocd-development] FA526: wrong pc value

2009-11-15 Thread Øyvind Harboe
Shot in the dark: set dbgreq_adjust_pc = 2 in fa526.c... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de http

Re: [Openocd-development] ARM NAND I/O: Read Function

2009-11-15 Thread David Brownell
On Sunday 15 November 2009, Zach Welch wrote: > > > Refactoring can come later. > > Personally, I think refactoring should come first, along with a patch to > hook up this routine into the system.  Right now, it's dangling unused. I took it as a "is this part good enough to merge?" query; answer

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread David Brownell
On Sunday 15 November 2009, Michael Bruck wrote: > >>> The macro is right above the table. Yep. At least, *now* it's right above. > >> The problem with this sort of macros is that ... it doesn't really add anything. Even though it *is* right above that table, you still have to think more abou

Re: [Openocd-development] ARM NAND I/O: Read Function

2009-11-15 Thread Dean Glazeski
> > Personally, I think refactoring should come first, along with a patch to > hook up this routine into the system. Right now, it's dangling unused. > It won't go unused for long :). > > I have been working hard to eliminate duplicated code, so I am not eager > to see more entering the tree.

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread Michael Bruck
On Sun, Nov 15, 2009 at 16:49, Michael Bruck wrote: > On Sun, Nov 15, 2009 at 16:39, Øyvind Harboe wrote: >> On Sun, Nov 15, 2009 at 4:26 PM, Michael Bruck wrote: >>> On Sun, Nov 15, 2009 at 10:08, Øyvind Harboe >>> wrote: On Sun, Nov 15, 2009 at 3:48 AM, David Brownell wrote:

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread Michael Bruck
On Sun, Nov 15, 2009 at 16:39, Øyvind Harboe wrote: > On Sun, Nov 15, 2009 at 4:26 PM, Michael Bruck wrote: >> On Sun, Nov 15, 2009 at 10:08, Øyvind Harboe wrote: >>> On Sun, Nov 15, 2009 at 3:48 AM, David Brownell wrote: Three changes:  remove ARM11_HANDLER() in favor of normal structure

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread Øyvind Harboe
On Sun, Nov 15, 2009 at 4:26 PM, Michael Bruck wrote: > On Sun, Nov 15, 2009 at 10:08, Øyvind Harboe wrote: >> On Sun, Nov 15, 2009 at 3:48 AM, David Brownell wrote: >>> Three changes:  remove ARM11_HANDLER() in favor of normal structure >> >> I like this cleanup. It makes it possible to read co

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread Michael Bruck
On Sun, Nov 15, 2009 at 10:08, Øyvind Harboe wrote: > On Sun, Nov 15, 2009 at 3:48 AM, David Brownell wrote: >> Three changes:  remove ARM11_HANDLER() in favor of normal structure > > I like this cleanup. It makes it possible to read code without > special knowledge about ARM11 helper macros... >

[Openocd-development] FA526: wrong pc value

2009-11-15 Thread Peter Schildmann
Hi, I have just tested OpenOCD 0.3.1 with a StorLink SL3516 (Gemini) SoC. This SoC contains a FA526 ARM CPU core and all the peripherials needed for NAS, Router, and similar applications. (The system is an IB-NAS4220-B which fortunately has a 20-pin JTAG on its mainboard.) The problem: The pc dis

Re: [Openocd-development] BUG: Configure needs installed(!) JTAG dongle drivers

2009-11-15 Thread Thomas Kindler
Thomas Kindler wrote: > David Brownell wrote: >>> Perhaps we shouldn't link to ftd2xx.lib at all. Instead, OpenOCD could >>> use LoadLibrary and GetProcAddress calls to load the .dll at runtime. >>> >>> Wouldn't this also solve the GPL problem?! >> No it wouldn't. We've been over that before. >>

Re: [Openocd-development] Unable to build OpenOCD PDF documentation using Cygwin

2009-11-15 Thread Ferdinand Postema
That is not the problem. I had te read the mailinglist fisrt, because the solution of Daniel Bäder is much better! Set the TEX environment variable: "/export TEX=tex". Best regards, Ferdinand Zach Welch wrote: > Did you use --enable-maintainer-mode when running configure? > I believe that wil

[Openocd-development] Unable to build OpenOCD PDF documentation using Cygwin

2009-11-15 Thread Ferdinand Postema
Sorry, I have to read the reactions first, before sending my reaction. The solution of /Daniel Bäder is much better! Set the TEX environment variable: "/export TEX=tex". Best regards, Ferdinand ___ Openocd-development mailing list Openocd-development@l

Re: [Openocd-development] Unable to build OpenOCD PDF documentation using Cygwin

2009-11-15 Thread Zach Welch
Did you use --enable-maintainer-mode when running configure? I believe that will fix this particular problem. --Z On Sun, 2009-11-15 at 13:16 +0100, Ferdinand Postema wrote: > Hi Peter, > > I had the same problem. It seems that the new version of tetex (version > 3.0.0-3) is causing the problem

[Openocd-development] Unable to build OpenOCD PDF documentation using Cygwin

2009-11-15 Thread Ferdinand Postema
Hi Peter, I had the same problem. It seems that the new version of tetex (version 3.0.0-3) is causing the problem. If you reverting to tetex-2.0.2-15, than the problem is gone. Of course, this is not a solution,... but it is a work-around. Best regards, Ferdinand Postema - Pieter Conrad

Re: [Openocd-development] Cygwin compile errors

2009-11-15 Thread Ferdinand Postema
Hello, I tried again with latest version of cygwin + lattest version of master branch. I don't get warnings while compiling the source code, but I get error while compiling the documentation. It seems that the new version of tetex (version 3.0.0-3) is cousing the problem. Compile error on cygw

Re: [Openocd-development] ARM NAND I/O: Read Function

2009-11-15 Thread Zach Welch
On Sun, 2009-11-15 at 02:19 -0700, David Brownell wrote: > On Sunday 15 November 2009, Dean Glazeski wrote: > > I've done an implementation of reading using an on-chip algorithm for NAND > > devices attached to ARM chips. It seems to work on my AT91SAM9260 board > > increasing nand dump from 0.2 k

Re: [Openocd-development] [PATCH 05/11] bitbuffer: move variables to point of first use

2009-11-15 Thread Zach Welch
On Sat, 2009-11-14 at 12:49 -0700, David Brownell wrote: > For the record, I still prefer to see declarations grouped > at the beginning of their block, after a left bracket. > That way they're always easy to find. Rather than where they are first used, where you actually need the information to u

Re: [Openocd-development] [PATCH 08/11] improve buf_cpy helper

2009-11-15 Thread Zach Welch
On Sat, 2009-11-14 at 19:59 -0700, David Brownell wrote: > On Saturday 14 November 2009, Zach Welch wrote: > > On Sat, 2009-11-14 at 12:56 -0700, David Brownell wrote: > > > On Saturday 14 November 2009, Zachary T Welch wrote: > > > > - for (unsigned i = 0, num_bytes = CEIL(size, 8); i < num_

[Openocd-development] FA526: wrong pc value

2009-11-15 Thread Peter Schildmann
Hi, I have just tested OpenOCD 0.3.1 with a StorLink SL3516 (Gemini) SoC. This SoC contains a FA526 ARM CPU core and all the peripherials needed for NAS, Router, and similar applications. (The system is an IB-NAS4220-B which fortunately has a 20-pin JTAG on its mainboard.) The problem: The pc dis

[Openocd-development] Get rid of buf_set_u32()'s

2009-11-15 Thread Øyvind Harboe
There's lots of these around the code: fields[2].out_value = field2_out; buf_set_u32(fields[2].out_value, 0, 5, 7); /* set bit 0-4 to 7*/ This could be rewritten to: fields[2].out_value = field2_out; field2_out[0]=7; /* set bit 0-4 to 7 */ -- Øyvind Harboe http

Re: [Openocd-development] ARM NAND I/O: Read Function

2009-11-15 Thread David Brownell
On Sunday 15 November 2009, Dean Glazeski wrote: > I've done an implementation of reading using an on-chip algorithm for NAND > devices attached to ARM chips.  It seems to work on my AT91SAM9260 board > increasing nand dump from 0.2 kb/s to 9.2 kb/s.  Not sure if this is the > best implementation,

Re: [Openocd-development] [patch 3/4] ARM11: fixup method table

2009-11-15 Thread Øyvind Harboe
On Sun, Nov 15, 2009 at 3:48 AM, David Brownell wrote: > Three changes:  remove ARM11_HANDLER() in favor of normal structure I like this cleanup. It makes it possible to read code without special knowledge about ARM11 helper macros... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9

[Openocd-development] ARM NAND I/O: Read Function

2009-11-15 Thread Dean Glazeski
Hi all, I've done an implementation of reading using an on-chip algorithm for NAND devices attached to ARM chips. It seems to work on my AT91SAM9260 board increasing nand dump from 0.2 kb/s to 9.2 kb/s. Not sure if this is the best implementation, so take a look. By the way, there is some room