> 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
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
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
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
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
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
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
_
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);
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
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
[ 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
[ 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
[ *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
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
> 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
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.
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
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.
---
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
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
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.
---
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
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
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
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
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
>
> 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.
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:
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
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
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...
>
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
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.
>>
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
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
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
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
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
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
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
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_
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
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
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,
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
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
46 matches
Mail list logo