On Friday 30 October 2009, Øyvind Harboe wrote:
> Deleted unused fn's in interfaces. Unused fn's will be copy & pasted
> around the code, get rid of it.
>
> Keeping it in a dev branch until after 0.3.
>
> See head of:
>
> http://repo.or.cz/w/openocd/oharboe.git?a=shortlog;h=refs/heads/remove_pre
On Wednesday 28 October 2009, Zach Welch wrote:
> Hi all,
>
> Please check the NEWS file to ensure that it notes everything worthy of
> mention for 0.3.0 release.
I merged the following.
= CUT HERE
From: David Brownell
Subject: NEWS: more info
There were a few more changes wo
For some reason, all the interals are documented by default.
This seems wrong for two basic reasons:
- We need to focus on public interfaces, since they're the
ones that expose the architectural relationships.
- Since virtually nothing has doxygen support yet, this
just maximizes the amou
On Fri, 30 Oct 2009, David Brownell wrote:
> On Friday 30 October 2009, Nicolas Pitre wrote:
> > I really don't like this pointer business. No type checking at all,
> > etc. This should be turned upside down as you suggested already: embed
> > more generic structures within the more specific o
On Friday 30 October 2009, Nicolas Pitre wrote:
> On Fri, 30 Oct 2009, David Brownell wrote:
>
> > @@ -906,7 +906,9 @@ static int arm926ejs_virt2phys(struct ta
> > static int arm926ejs_mmu(struct target_s *target, int *enabled)
> > {
> > armv4_5_common_t *armv4_5 = target->arch_info;
> > -
On Fri, 30 Oct 2009, David Brownell wrote:
> I'm suspecting this code can never have worked, since the
> original commit (svn #335) in early 2008.
>
> Fix is just copy/paste from another (working) function.
> ---
> src/target/arm926ejs.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion
On Friday 30 October 2009, Dean Glazeski wrote:
> There are two interface scripts that are essentially the same: luminary.cfg
> and luminary-lm3s811.cfg. The only difference is the ft2232_device_desc.
That is, the string. I think only Windows cares about that.
> Can anyone verify that we need b
I'm suspecting this code can never have worked, since the
original commit (svn #335) in early 2008.
Fix is just copy/paste from another (working) function.
---
src/target/arm926ejs.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/src/target/arm926ejs.c
+++ b/src/target/arm926e
On Friday 30 October 2009, Øyvind Harboe wrote:
> Is there a way to translate between svn and git version #'s?
First, stop using SVN numbers for new work.
But for cross referencing, "git log" will include the
SVN linear ID in the commits pulled via "git svn".
You can see one with e.g. "git show
On Friday 30 October 2009, Wookey wrote:
>
> > > Cheers very much for that. Now to see if the 'only works on amd64' and
> > > 'only works every other time' bugs from r1613 have gone in latest :-)
> >
> > I was curious about that. Could that XScale stackframe
> > corruption bugfix have been the i
Hello,
There are two interface scripts that are essentially the same: luminary.cfg
and luminary-lm3s811.cfg. The only difference is the ft2232_device_desc.
Can anyone verify that we need both? If we do, any naming suggestions since
they seem to be for the same development board?
// Dean Glazesk
On Friday 30 October 2009, David Brownell wrote:
> On Thursday 29 October 2009, Dimitar Dimitrov wrote:
> > I fixed the issue by disabling dcc memory uploads.
>
> Bizarre. Disabling those let the initial enumeration
> work at full speed?? Or was that caused by some other
> patches in your reposi
Hi !
This is a simple jtag-driver over the serial cable (it is rare, but
was given to me :)
TCK == !RTS (out);
TMS == !DTR (out);
TDI == TXD (out, control by break-signal);
TDO == !CTS (in);
led and reset - not available.
This code is working (tested on Linux - ARM7TDMI core-i
I'm currently renaming configuration scripts to match a standard naming
convention decided on a while back and I was wondering what the heck the
telo.cfg is for. I can't seem to find it anywhere on the internet and C100
maps to a Samsung phone and a bunch of other stuff. Can anyone send my a
link
2009/10/30 David Brownell :
> On Friday 30 October 2009, Pieter Conradie wrote:
>> It took me a while to set up an automated build process
>> so that I could do a SVN binary search. Here are the results:
>
> Good results ... but for the record, "git bisect" is
> a lot easier when you're doing a bin
On Friday 30 October 2009, Pieter Conradie wrote:
> It took me a while to set up an automated build process
> so that I could do a SVN binary search. Here are the results:
Good results ... but for the record, "git bisect" is
a lot easier when you're doing a binary search. :)
__
Deleted unused fn's in interfaces. Unused fn's will be copy & pasted
around the code, get rid of it.
Keeping it in a dev branch until after 0.3.
See head of:
http://repo.or.cz/w/openocd/oharboe.git?a=shortlog;h=refs/heads/remove_pre_debug
Is it a good or bad idea to post patches just as links
> SVN 2645: writes 512k to flash, verifies correctly
> SVN 2646: flash write_image fails with "timed out while waiting for target
> debug-running"
Hmm. this is trickier than I thought
Can you provide debug_level 3 logs for 2645 and 2646?
Try to use the *EXACT* same procedure so the logs
On Fri, Oct 30, 2009 at 11:29 AM, Øyvind Harboe wrote:
>
> They are config files first and foremost, tcl configuration
> files secondly... I'm sure your favorite edit can switch
> to tcl coloring w/a .cfg file... ?
You are correct about that one. I was just curious. Plus, I was
considering doi
On Fri, Oct 30, 2009 at 5:04 PM, Dean Glazeski wrote:
> There was something that was recently bothering me. Is there any reason we
> don't name the configuration scripts with the extension '.tcl'? Aren't they
> essentially TCL scripts? I figure it would help syntax highlighting
> programs, like
There was something that was recently bothering me. Is there any reason we
don't name the configuration scripts with the extension '.tcl'? Aren't they
essentially TCL scripts? I figure it would help syntax highlighting
programs, like vim or the TCL editor from Eclipse DLTK, to actually
recognize
Well done! First rate testing!
> SVN 2646: flash write_image fails with "timed out while waiting for target
> debug-running"
I see that I broke run_algorithm when I fixed breakpoint handling...
I'll look into it.
This means the problem is not unique to arm926ejs and that it
is important to addr
On Fri, Oct 30, 2009 at 2:47 AM, David Brownell wrote:
> On Friday 30 October 2009, Dean Glazeski wrote:
> > --enable-ep93xx \
> > --enable-at91rm9200 \
>
> I'm amazed you can enable those on x86 builds. :)
> They're for different flavors of native ARM builds. ...
>
Not only x86 but PowerP
Hi Øyvind,
I don't know why I did not think earlier of narrowing it down more :( sorry!
It took me a while to set up an automated build process so that I could do a
SVN binary search. Here are the results:
OpenOCD_0.2.0: writes 512k to flash, verifies correctly
SVN 2617: writes 512k to flash, v
Hi, all,
We are glad to provide a set of our boards to the man who can help us to clear
the bugs for FA526 core(or just add CNS2132 support), especially to the man
who wrote the codes of FA526 core.
Thanks & Regards.
--
zzzh.2007
2009-10-30
I don't have this target hardware, so I'm loathe to look into
this.
Anyone else?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-developme
>
> On Fri, Oct 30, 2009 at 9:56 AM, Jerry Ling
> wrote:
> > FYI, the following is the compiler options that really
> executed from my
> > environment
> >
> > $ gcc -mno-cygwin -std=gnu99 -g -O0 -Wall -Wstrict-prototypes
> > -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast
>
+++ David Brownell [2009-10-29 12:37 -0700]:
> On Thursday 29 October 2009, Wookey wrote:
> >
> > Cheers very much for that. Now to see if the 'only works on amd64' and
> > 'only works every other time' bugs from r1613 have gone in latest :-)
>
> I was curious about that. Could that XScale stack
On Fri, Oct 30, 2009 at 9:56 AM, Jerry Ling wrote:
> FYI, the following is the compiler options that really executed from my
> environment
>
> $ gcc -mno-cygwin -std=gnu99 -g -O0 -Wall -Wstrict-prototypes
> -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast
> -Wcast-align -Wredund
> On Fri, Oct 30, 2009 at 9:07 AM, Jerry Ling
> wrote:
> > You're right.
> > Yes, the problem comes from the file conversion. So the
> converter need to be
> > fixed.
>
> Or perhaps the build options to bin2char are wrong. It should
> be built for the
> build OS and not the OpenOCD host OS.
>
On Thu, Oct 29, 2009 at 12:50:53PM -0700, David Brownell wrote:
> On Thursday 29 October 2009, Pavel Kurochkin wrote:
> > May be somebody tried to communicate with such hardware (PXA320
> > or NAND flash).
>
> I don't see any PXA flash driver in src/flash, so I'm
> guessing not ... the earlier ge
FYI, the following is the compiler options that really executed from my
environment
$
gcc -mno-cygwin -std=gnu99 -g -O0 -Wall -Wstrict-prototypes -Wformat-security
-Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align
-Wredundant-decls
-Werror ./bin2char.c -o bin2char.exe
I build
On Fri, Oct 30, 2009 at 9:07 AM, Jerry Ling wrote:
> You're right.
> Yes, the problem comes from the file conversion. So the converter need to be
> fixed.
Or perhaps the build options to bin2char are wrong. It should be built for the
build OS and not the OpenOCD host OS.
E.g. did -mno-cygwin sne
On Fri, Oct 30, 2009 at 9:07 AM, Jerry Ling wrote:
> You're right.
> Yes, the problem comes from the file conversion. So the converter need to be
> fixed.
Or perhaps it is a build problem in that -mno-cygwin sneaks into the
compile options
for the converter?
The converter application should be b
You're right.
Yes, the problem comes from the file conversion. So the converter need to be
fixed.
Thanks Dave.
- Original Message -
> On Thursday 29 October 2009, Jerry Ling wrote:
>> Thanks for improving the way to load debug handler...
>>
>> However, I got a problem while doing the bi
On Friday 30 October 2009, Dean Glazeski wrote:
> --enable-ep93xx \
> --enable-at91rm9200 \
I'm amazed you can enable those on x86 builds. :)
They're for different flavors of native ARM builds. ...
___
Openocd-development mailing list
Openocd-devel
On Thursday 29 October 2009, Jerry Ling wrote:
> Thanks for improving the way to load debug handler...
>
> However, I got a problem while doing the bin2char conversion under Cygwin
>$ bin2char xscale_debug_handler < debug_handler.bin > xscale_debug.h
>
> It treats the character "0x1A" as the
On Friday 30 October 2009, Øyvind Harboe wrote:
> Adding support for mrc/mcr interface in XScale in a sensible fashion
> would require updating debug_handler.S.
>
> Could I define a generic execute mrc/mcr command and rely on
> self modifying code?
No. Best if you use the approach outlined in on
Hello,
I've put together the spec file and a series of RPMs for submission to
Fedora once 0.3.0 is out the door. These are built based on the rc0
tarball. Anyone out there with Fedora who can test one of these will be
much appreciated.
http://files.dinoprojects.com/openocd/rpms/
For some of th
Thanks for improving the way to load debug handler...
However, I got a problem while doing the bin2char conversion under Cygwin
$ bin2char xscale_debug_handler < debug_handler.bin > xscale_debug.h
It treats the character "0x1A" as the EOF. So it stopped converting at
offset 0x22 of debug_hand
Adding support for mrc/mcr interface in XScale in a sensible fashion
would require updating debug_handler.S.
Could I define a generic execute mrc/mcr command and rely on
self modifying code?
- r0 - input value
- instruction - 32 bit value with instruction to execute
- r0 - output value
That woul
41 matches
Mail list logo
