On Wednesday 13 May 2009, Øyvind Harboe wrote:
> On Wed, May 13, 2009 at 11:01 PM, Nicolas Pitre wrote:
> > On Wed, 13 May 2009, David Brownell wrote:
> >
> >> When I tried "-d 3" it suddenly worked, and has worked
> >> again since. Note -- this is with *NO* rebuild, and
> >> using an executable
On Wed, May 13, 2009 at 11:01 PM, Nicolas Pitre wrote:
> On Wed, 13 May 2009, David Brownell wrote:
>
>> When I tried "-d 3" it suddenly worked, and has worked
>> again since. Note -- this is with *NO* rebuild, and
>> using an executable which previously failed.
>
> This is scary. Anyone with va
On May 13, 2009, at 8:42 PM, Zach Welch wrote:
On Wed, 2009-05-13 at 16:42 -0700, Rick Altherr wrote:
On May 13, 2009, at 3:41 PM, Edgar Grimberg wrote:
But at the end, I got a ld error like:
ld: duplicated symbol _Jim_SetResult_sprintf
Mac OS X 10.5.7 and GCC 4.0.1
I had no problems with
On Wed, 2009-05-13 at 16:42 -0700, Rick Altherr wrote:
> On May 13, 2009, at 3:41 PM, Edgar Grimberg wrote:
>
> >>> But at the end, I got a ld error like:
> >>>
> >>> ld: duplicated symbol _Jim_SetResult_sprintf
> >>>
> >>> Mac OS X 10.5.7 and GCC 4.0.1
> >>>
> >>> I had no problems with the old b
On Thu, May 14, 2009 at 2:12 AM, Edgar Grimberg
wrote:
>>
>> Fixed on my rocket.
>>
>
> Now I get something else:
>
> /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Wall
> -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter
> -Wbad-function-cast -Wcast-align -Wr
>
> Fixed on my rocket.
>
Now I get something else:
mac-mini:build edgar$ rm -rf *
mac-mini:build edgar$ ../configure --enable-maintainer-mode --enable-dummy
.
onfigure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.statu
On Thu, May 14, 2009 at 1:41 AM, Zach Welch wrote:
> On Thu, 2009-05-14 at 01:00 +0200, Edgar Grimberg wrote:
>> >> Right. I forgot about this madness. *sigh* An updated bootstrap
>> >> script has been committed as r1779.
>> >
>> > The attached patch does the trick for bootstrap. :)
>> >
>>
>>
On May 13, 2009, at 3:41 PM, Edgar Grimberg wrote:
But at the end, I got a ld error like:
ld: duplicated symbol _Jim_SetResult_sprintf
Mac OS X 10.5.7 and GCC 4.0.1
I had no problems with the old build where libtoolize
is not needed.
Did the transition leave around any old objects in your
On Thu, 2009-05-14 at 01:00 +0200, Edgar Grimberg wrote:
> >> Right. I forgot about this madness. *sigh* An updated bootstrap
> >> script has been committed as r1779.
> >
> > The attached patch does the trick for bootstrap. :)
> >
>
> Now that we are at MacOS issues, when I do:
>
> mac-mini:bu
On Thu, 2009-05-14 at 00:41 +0200, Edgar Grimberg wrote:
> Hi,
>
>
> > Right. I forgot about this madness. *sigh* An updated bootstrap
> > script has been committed as r1779.
>
> The attached patch does the trick for bootstrap. :)
D'oh. Fixed in r1780. Thanks. :)
> >> But at the end, I go
>> Right. I forgot about this madness. *sigh* An updated bootstrap
>> script has been committed as r1779.
>
> The attached patch does the trick for bootstrap. :)
>
Now that we are at MacOS issues, when I do:
mac-mini:build edgar$ ../configure --enable-maintainer-mode --enable-dummy
I get:
ch
Hi,
> Right. I forgot about this madness. *sigh* An updated bootstrap
> script has been committed as r1779.
The attached patch does the trick for bootstrap. :)
>> But at the end, I got a ld error like:
>>
>> ld: duplicated symbol _Jim_SetResult_sprintf
>>
>> Mac OS X 10.5.7 and GCC 4.0.1
>>
There might be some confusion about the focus on r1606
So let me clarify:
This is the revision I work from.
This where I am testing the new jtag transition table stuff, I have had
everything working and then suddenly it breaks, and I thaught everyting
was identical. It is confusing.
A lot of
On May 14, 2009, at 0:06, Michael Fischer wrote:
> Hello list,
>
> please can some one test if it is possible
> to build the 1770 on Mac OS X?
> Here I need libtoolize, but this was not found,
> even if I install libtool over mac port.
> I only found glibtoolize, therefore I set a symbolic
> link
On Wed, 2009-05-13 at 23:06 +0200, Michael Fischer wrote:
> Hello list,
>
> please can some one test if it is possible
> to build the 1770 on Mac OS X?
>
> Here I need libtoolize, but this was not found,
> even if I install libtool over mac port.
>
> I only found glibtoolize, therefore I set a
Zach Welch wrote:
> Magnus, (resent w/ Reply-All... oops)
>
> Please let me know if there is anything that I can do to help this
> situation. I am sorry that you are so frustrated right now, and I wish
> there was something that I could have done to prevent it.
>
> Z
>
>
The question is well r
Magnus, (resent w/ Reply-All... oops)
Please let me know if there is anything that I can do to help this
situation. I am sorry that you are so frustrated right now, and I wish
there was something that I could have done to prevent it.
Z
On Wed, 2009-05-13 at 19:04 +0200, Magnus Lundin wrote:
>
On Wed, 2009-05-13 at 17:01 -0400, Nicolas Pitre wrote:
> On Wed, 13 May 2009, David Brownell wrote:
>
> > When I tried "-d 3" it suddenly worked, and has worked
> > again since. Note -- this is with *NO* rebuild, and
> > using an executable which previously failed.
>
> This is scary. Anyone wi
Hello list,
please can some one test if it is possible
to build the 1770 on Mac OS X?
Here I need libtoolize, but this was not found,
even if I install libtool over mac port.
I only found glibtoolize, therefore I set a symbolic
link to libtoolize.
But at the end, I got a ld error like:
ld: du
On Wed, 13 May 2009, David Brownell wrote:
> When I tried "-d 3" it suddenly worked, and has worked
> again since. Note -- this is with *NO* rebuild, and
> using an executable which previously failed.
This is scary. Anyone with valgrind skills?
Nicolas
Hmm, this is quite squirrely. I had done a "make clean"
then rebuilt before reporting the failures ... but a build
which previously failed, has just started to work.
On Wednesday 13 May 2009, Øyvind Harboe wrote:
> > Current GIT head no longer starts up correctly on dm355.
> > It should find thr
Hello list,
here is a new test which I had make with r1606 / r1770,
done with a FT2232 device. The result look like:
Windows-ft2232-1606
Open On-Chip Debugger
> version
Open On-Chip Debugger 0.2.0-in-development (2009-05-13-21:55) svn:1606
> load_image testimg.bin 0x8100
On Wed, 13 May 2009, David Brownell wrote:
> On Wednesday 13 May 2009, Øyvind Harboe wrote:
> > If you have any problems please report them.
> >
> > All known functional and performance regressions since 1606
> > are now fixed in svn head.
>
> Current GIT head no longer starts up correctly on dm
On Wed, May 13, 2009 at 9:33 PM, David Brownell wrote:
> On Wednesday 13 May 2009, Řyvind Harboe wrote:
>> If you have any problems please report them.
>>
>> All known functional and performance regressions since 1606
>> are now fixed in svn head.
>
> Current GIT head no longer starts up correctly
Hello List,
it is possible that I have make to much testing here
and mixed something. I will start with a clean build.
>What I find curious about the lpc2294.cfg and your posting above
>is that working memory is at 0x4000.
It is a olimex LPC-2294 board with external RAM.
I will test it again
On Wednesday 13 May 2009, Øyvind Harboe wrote:
> If you have any problems please report them.
>
> All known functional and performance regressions since 1606
> are now fixed in svn head.
Current GIT head no longer starts up correctly on dm355.
It should find three TAPs: ICEpick, ARM926ejs, ETB11
Referring to our offlist discussion: 1606 has the same problem
per your testing.
What I find curious about the lpc2294.cfg and your posting above
is that working memory is at 0x4000.
Does the lpc2294 have two ram regions?
Could it be that the config script is busted and that working memory
Hello list,
please can some one try if the load_image is working?
I want to download data into an external RAM of the LPC2294
CPU. Interface is a FT2232 device, command looks like:
load_image test.bin 0x8100
The telnet prompt come back, but I could not
found any data at 0x8100.
The ext
>
> No, I still have the same problem with r1776.
>
> there are some uint32_t uses in replacement.h which are not recognized
> - I don't have an elf.h system include.
>
> export CPPFLAGS="-IC:/libusb-win32-device-bin-0.1.12.1/include"
> export LDFLAGS=-LC:/libusb-win32-device-bin-0.1.12.1/lib/gc
If you have any problems please report them.
All known functional and performance regressions since 1606
are now fixed in svn head.
We've even fixed one or two other bugs, e.g. irscan caused
segfault and shifted out the wrong values...
--
Øyvind Harboe
Embedded software and hardware consulting
Hi Nicolas,
nice work!
There at this point no known performance or functional regressions
in svn head then w.r.t. the API rewrite at least.
>> Another thing to test is to use "verify_jtag disable" that I
>> added this morning to svn head...
>
> I prefer not disabling any kind of self check featu
On Wed, 13 May 2009, Øyvind Harboe wrote:
> Hi Nicolas,
>
> I'm starting a new thread, because I worry that I was not clear
> in regards to my question about the residual performance
> degradation you are seing in svn head(10% degradation).
You were clear. I just didn't spare the time to perfor
I am so tired of this endless need unplanned for change.
And talk of planned and stable releases.
There are so much more important things to attend to in order to make
OpenOCD truly stable and versatile.
Debugging, regression testing, finding root causes of problems before
fixing them, the list
On Wed, May 13, 2009 at 6:11 PM, David Brownell wrote:
> On Wednesday 13 May 2009, Řyvind Harboe wrote:
>> >> Not always, TAP_INVALID is really TAP_DONTCARE
>> >
>> > I was wondering about that. Someone should rename it
>> > so it's no longer nonsense.
>>
>> The point
>
> Make that: "another" po
On Wed, May 13, 2009 at 6:19 PM, Magnus Lundin wrote:
> Øyvind Harboe wrote:
>> On Wed, May 13, 2009 at 4:40 PM, David Brownell wrote:
>>
>>> On Wednesday 13 May 2009, Magnus Lundin wrote:
>>>
Not always, TAP_INVALID is really TAP_DONTCARE
>>> I was wondering about that. Someone should
Strontium wrote:
> I haven't seen any Cortex A8 activity on the list, lately, so I wonder
> if anyone has come across these issues.
>
> See attached script:
>
> I tried implementing the functions described in the Cortex A8 TRM. I
> was trying to see if I could read CPU ARM registers.
>
> The cod
Øyvind Harboe wrote:
> On Wed, May 13, 2009 at 4:40 PM, David Brownell wrote:
>
>> On Wednesday 13 May 2009, Magnus Lundin wrote:
>>
>>> Not always, TAP_INVALID is really TAP_DONTCARE
>>>
>> I was wondering about that. Someone should rename it
>> so it's no longer nonsense.
>>
On Wednesday 13 May 2009, Øyvind Harboe wrote:
> >> Not always, TAP_INVALID is really TAP_DONTCARE
> >
> > I was wondering about that. Someone should rename it
> > so it's no longer nonsense.
>
> The point
Make that: "another" point.
> is to do away with "don't care", "default" and global var
On Wed, May 13, 2009 at 4:40 PM, David Brownell wrote:
> On Wednesday 13 May 2009, Magnus Lundin wrote:
>> Not always, TAP_INVALID is really TAP_DONTCARE
>
> I was wondering about that. Someone should rename it
> so it's no longer nonsense.
The point is to do away with "don't care", "default" an
I haven't seen any Cortex A8 activity on the list, lately, so I wonder
if anyone has come across these issues.
See attached script:
I tried implementing the functions described in the Cortex A8 TRM. I
was trying to see if I could read CPU ARM registers.
The code seems to mostly work.
Excep
On Wednesday 13 May 2009, Magnus Lundin wrote:
> Not always, TAP_INVALID is really TAP_DONTCARE
I was wondering about that. Someone should rename it
so it's no longer nonsense.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
ht
Hi Nicolas,
I'm starting a new thread, because I worry that I was not clear
in regards to my question about the residual performance
degradation you are seing in svn head(10% degradation).
I wonder if 1606 (before I made all these changes) is the
*same* speed as svn head.
If 1606 and svn head is
On Wed, May 13, 2009 at 4:21 PM, Magnus Lundin wrote:
> I have been giving this a lot of thought, and I would like to suggest a
> compromise :)
>
> I dont have the code with me right now so some of some function names
> ´might be a bit off but the idea should be clear.
>
>> One problem about jtag_
On Wed, May 13, 2009 at 1:21 PM, Zach Welch wrote:
> On Wed, 2009-05-13 at 03:17 -0700, Zach Welch wrote:
>> On Wed, 2009-05-13 at 12:00 +0200, Francois Lorrain wrote:
>> [snip]
>> > 2) It looks like the stdint.h need to be included in system.h, not
>> > types.h, otherwise binarybuffer.c does not
I have been giving this a lot of thought, and I would like to suggest a
compromise :)
I dont have the code with me right now so some of some function names
´might be a bit off but the idea should be clear.
> One problem about jtag_add_end_state() is that it's effectively
> setting a global variab
Zach Welch wrote:
> On Tue, 2009-05-12 at 17:59 -0400, Gene Smith wrote:
>> Someone loaned me an IAR evaluation board STR712 (made by Olimex) and a
>> yellow IAR J-link (marked J-LINK-ARM-KS on bottom). I had seen quite a
>> bit of mention on this list about jlink and thought I would give it a
One problem about jtag_add_end_state() is that it's effectively
setting a global variable.
This makes it hard to tell, reading some code, what is expected
to happen after a JTAG scan.
Some other calling code invoked jtag_add_end_state() with some
end state.
Other than running the debugger, I don
On Wed, May 13, 2009 at 10:29 AM, David Brownell wrote:
> On Tuesday 12 May 2009, Ųyvind Harboe wrote:
>> I've been thinking about whether some helper fn's to
>> use 32 bit arrays instead of 8 bit input/output might make sense.
>
> Why 32 bits instead of e.g. just plain "unsigned long"?
We're tal
> 4) This one is blocking, during the compilation of openocd.c,
> there is a syntax error around -DPKGBLDDATE=\"`date +%F-%R`\"
> I am not sure how to fix it ...
>
> mingw32-make[3]: Entering directory `c:/Workspace-1/openocd/src'
> C:/cygwin/bin/sh.exe ../libtool --tag=CC --mode=compile mi
On Wed, 2009-05-13 at 03:17 -0700, Zach Welch wrote:
> On Wed, 2009-05-13 at 12:00 +0200, Francois Lorrain wrote:
> [snip]
> > 2) It looks like the stdint.h need to be included in system.h, not
> > types.h, otherwise binarybuffer.c does not compile
>
> I have a better fix in mind; please do not a
On Tue, 2009-05-12 at 00:19 +0200, Nico Coesel wrote:
[snip]
> Allright! I need to write a driver somewhere in the next couple of
> weeks/months (when the JTAG programmer hardware arrives). Perhaps I
> can sketch/write some outlines on putting a driver together. I just
> don't know how this would w
Patch contains command to disable checking value + mask.
verify_jtag disables ircapture verification too.
A dramatic effect on USB performance(>5-10%) would be surprising and
grounds for investigating if there is something wrong with drivers/JTAG
layer.
--
Øyvind Harboe
Embedded software and ha
On Wed, 2009-05-13 at 12:00 +0200, Francois Lorrain wrote:
[snip]
> 2) It looks like the stdint.h need to be included in system.h, not
> types.h, otherwise binarybuffer.c does not compile
I have a better fix in mind; please do not apply this patch. Thanks.
--Z
___
Hello,
Trying to compile the SVN version after the recent changes on windows
I am compiling a mingw version using the cygwin tools with
mingw32-make, mingw32-gcc - it has worked for me before.
I have a couple of issue with one blocking from finishing the compilation.
1) I have a small local patc
Hi all,
The following documentation files seem like they should be moved into
the doc/ directory:
src/scripting.txt
src/server/httpd/readme.txt
src/non-arm-targets.txt
src/tcl/README_ABOUT_TCL.txt
src/target/target/readme.txt
Given the new doxygen manual skeleton from r1771, I am think
Magnus Lundin wrote:
> Magnus Lundin wrote:
>
>> When I do this for the Beagle i just use
>>
>> # set the current target, should not be nexessary with only one target
>> configured
>> targets omap3.cpu
>> # call tcl functions without the extra target name
>> mem2array dataval 32 [expr "0x54011
Hi all,
In r1771, I committed an initial skeleton of files that begin to
transform Doxygen's output into a genuine OpenOCD Developer Manual.
I know that I probably missed some important structural bones, but I am
still learning OpenOCD's anatomy. When it is done, that learning curve
should be muc
On Tuesday 12 May 2009, Øyvind Harboe wrote:
> I've been thinking about whether some helper fn's to
> use 32 bit arrays instead of 8 bit input/output might make sense.
Why 32 bits instead of e.g. just plain "unsigned long"?
I know the bit vector utilities in Linux use "unsigned long",
which mostl
On Wed, 2009-05-13 at 08:53 +0100, John Devereux wrote:
> Zach Welch writes:
> > On Tue, 2009-05-12 at 23:24 +0200, Freddie Chopin wrote:
[snip]
> > [...]
> >> comfortable situation, because I know how to compile the package, but -
> >> believe me - there are hundreds of "domestic ARM developers"
Zach Welch writes:
> On Tue, 2009-05-12 at 23:24 +0200, Freddie Chopin wrote:
>> Sorry to interrupt (; I thought that I'd share my "outsider's opinion"
>> with all.
>
> Not at all. I hope more folks are willing to step up and share their
> opinions; without feedback, the maintainers cannot know
> I have it in my current "stable" work copy, based on 1606, together with
> some other small but potentially useful modifications that I am testing.
> Of course you can have a svn diff -r 1606.
> I have no I idea how much it is to get it into head and at the moment I
> would rather use my time for
Magnus Lundin wrote:
> When I do this for the Beagle i just use
>
> # set the current target, should not be nexessary with only one target
> configured
> targets omap3.cpu
> # call tcl functions without the extra target name
> mem2array dataval 32 [expr "0x54011000 + $reg_num * 4"] 1
>
>
And t
When I do this for the Beagle i just use
# set the current target, should not be nexessary with only one target
configured
targets omap3.cpu
# call tcl functions without the extra target name
mem2array dataval 32 [expr "0x54011000 + $reg_num * 4"] 1
Regards
Magnus
Strontium wrote:
> Hmm,
>
> S
63 matches
Mail list logo
