On Fri, Oct 21, 2011 at 1:36 PM, Freddie Chopin wrote:
> On 2011-10-21 19:09, Øyvind Harboe (Code Review) wrote:
>> Please look up the discussion of why this code was modified to use
>> uplevel and amend the commit with an explanation of why we should use
>> the proposed behaviour instead.
>
> I c
On Fri, Sep 2, 2011 at 10:58 AM, Øyvind Harboe wrote:
>> Jim_Eval_Named is a macro. I don't know why it's not substituted when
>> preprocessing. Maybe make clean will help you. Maybe you need to
>> remove the ccache cache and try again.
>
> I've tried what I can think of:
>
> rm -rf ~/.ccache
> gi
On Fri, Sep 2, 2011 at 10:37 AM, Øyvind Harboe wrote:
> Not sure why I can't build today
>
>
> ccache cc -g -O2 -rdynamic -o jimsh jimsh.o _initjimsh.o libjim.a -ldl
> libjim.a(jim-stdlib.o): In function `Jim_stdlibInit':
> /home/oyvind/workspace/openocd/jimtcl/jim-stdlib.c:7: undefined
> ref
Ping.
Jie
On Sat, Aug 27, 2011 at 11:01 AM, Jie Zhang wrote:
> Hi Evan,
>
> If qThreadExtraInfo is not implemented, qP will be used. But since
> qThreadExtraInfo has now been implemented, qP should not be needed any
> more. GDB added qThreadExtraInfo more than 10 years ago. All
On Tue, Aug 30, 2011 at 5:26 AM, Øyvind Harboe wrote:
> Goal: switch OpenOCD to use the Kernel coding style
>
> Plan:
>
> a) get all outstanding patches merged
> b) do wholesale automated(hopefully) code style fix
> d) patch w/documentation and scripts to enforce the new coding style.
>
> Resource
On Mon, Aug 29, 2011 at 7:35 AM, Øyvind Harboe wrote:
> I don't mind picking the kernel style, if nothing else because we then can get
> scripts to check for the style.
>
It seems people like Linux kernel coding style. It's widely used and
well documented. So I think it will be good.
How about ma
On Sat, Aug 27, 2011 at 5:49 PM, j. m. norris wrote:
>
> There is a tool that has been around for a long time that can
> address this issue. It's called indent. It has numerous options
> that can generate just about any type of coding style.
>
I don't know if indent can check in-line coding style.
On Sat, Aug 27, 2011 at 1:40 PM, Øyvind Harboe wrote:
> As a maintainer I'm interested in this subject from the point of view
> of how it can be used to *save* time of the maintainers.
>
> E.g. if we had a script committed that checked that a patch sequence
> was acceptable, then that report could
On Fri, Aug 26, 2011 at 2:18 PM, Andreas Fritiofson
wrote:
> The ftdi driver is a real mess. I've been trying to clean in up the past
> days but I'm beginning to think a complete rewrite would be better.
Maybe making OpenOCD use UrJTAG as a library is more worth the effort
than just rewriting ftd
2011/8/26 Michel Catudal :
> Le 25/08/2011 15:18, Jie Zhang a écrit :
>>
>> Hi,
>>
>> There are a lot of coding style mismatch in the current OpenOCD code.
>> I'd like suggest setting a rule that asks fixing all coding style
>> issues before a patch is
pse I found that OpenOCD received "qP"
> packets sometimes, and I think I implemented it first, before reading that
> same quotation you mentioned. Then when I implemented qThreadExtraInfo, I
> figured it was nicer to keep "qP" compatibility too.
>
> Regards,
>
Hi,
There are a lot of coding style mismatch in the current OpenOCD code.
I'd like suggest setting a rule that asks fixing all coding style
issues before a patch is merged.
And there are still something missing on
http://openocd.berlios.de/doc/doxygen/html/stylec.html , like
* how to deal with l
Hi Evan,
I'm wondering why threadid_t is int64_t. Is there any known RTOS needs
int64_t for its thread id? Can it be long?
Regards,
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/o
Hi Evan,
GDB manual says about "qP":
Don't use this packet; use the `qThreadExtraInfo' query instead (see below).
Since "qThreadExtraInfo" is already supported in rtos.c, why "qP" is
still needed?
Regards,
Jie
___
Openocd-development mailing list
On Thu, Aug 25, 2011 at 2:12 AM, Øyvind Harboe wrote:
> Hi,
>
> is anyone out there working on something that they would like
> to see in the next release?
>
> I know Tomek has been working on SWD. Here we need resources
> to review, give feedback and look into what it would take to bring
> this t
s a good idea. Ideally the function should be put in
gdb_server.c. But currently it needs to be in gdb_server.h. The new
patch is attached.
Regards,
Jie
From 8b73e67c7fcdfd0228d5cc2326bff47635daf84c Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Wed, 24 Aug 2011 11:23:04 -0400
Subject: [PATCH] rem
?
Regards,
Jie
From 9d7c77df0ba54d659bc995b997d74411f433eb3e Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Tue, 23 Aug 2011 17:29:29 -0400
Subject: [PATCH] remove target argument from gdb packet handling functions
---
src/rtos/rtos.c | 10 +++-
src/rtos/rtos.h |4 +-
src/server
On Thu, Aug 18, 2011 at 4:33 PM, Øyvind Harboe wrote:
>> But if we treat each target as a thread, we will need something as
>> thread id. target_number is good for this purpose. Does keeping
>> target_number hurt?
>
> I'm not sure that the current target number scheme is suitable
> for this purpos
On Thu, Aug 18, 2011 at 4:18 PM, Øyvind Harboe wrote:
> target_number should be retired. Patches gladly accepted.
>
> The only slight hickup is to get rid of current_target, near as I can tell.
>
> Targets are identified only by strings from tcl.
>
But if we treat each target as a thread, we will
Hi,
I saw this
int target_number; /* DO NOT USE! field to be removed in 2010 */
in the definition of "struct target". I don't know the reason to
remove it. Maybe it's just useless? I I need a way to identify each
target. I think target_number is good for this purpose.
Regards,
Jie
Hi,
This is a trivial patch. Please help me merge it. Thank you.
Regards,
Jie
From 852d698ba7237908c44a335a5efbe08e1dfdef6d Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Wed, 17 Aug 2011 11:21:22 -0400
Subject: [PATCH] remove white space before TAB
---
src/target/Makefile.am |2 +-
1
On Mon, Aug 15, 2011 at 6:21 PM, Andreas Fritiofson
wrote:
> > +if test -f $srcdir/guess-rev.sh ; then
> Great, but you should probably check if it's executable instead of just a
> regular file.
I considered if we should check this. But I finally decided it would
be better to just check if it's
On Mon, Aug 15, 2011 at 4:42 PM, Øyvind Harboe wrote:
> On Mon, Aug 15, 2011 at 9:16 PM, Jie Zhang wrote:
>> On Mon, Aug 15, 2011 at 3:10 PM, Øyvind Harboe
>> wrote:
>>> Isn't there a way to make both live side-by-side?
>>>
>>> rtos w/BF561
configure.ac is now preferred. So rename configure.in to make OpenOCD
project look modern.
Please review and merge if it's OK.
Thank you!
Jie
From 97ef0e24eeb752f88e521376f41b8e1321db52a0 Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Mon, 15 Aug 2011 15:35:30 -0400
Subject: [PATCH] r
On Mon, Aug 15, 2011 at 3:10 PM, Øyvind Harboe wrote:
> Isn't there a way to make both live side-by-side?
>
> rtos w/BF561 is surely possible?
>
Since both will use threads, they cannot be supported in the same
time. To debug a rtos on BF561, users have to choose using thread in
GDB as a core or a
Hi,
I remember there was a configure option to enable/disable rtos in the
first version of the rtos patches. But when it was committed, this
configure option was removed. I'm currently considering using
multi-thread model for debugging multi-core processor, for example
dual-core BF561. This will c
f/00fad24996d6642c6a820cc951c197dddef5734a
>>
Actually it was introduced earlier
http://repo.or.cz/w/openocd.git/commit/64e53c4fd8a5da944de57716b137a7dff5e67b63
This patch should fix it. Please review and merge if it's OK. Thank you!
Jie
From 281bc87c50fd108d43283b07ac1d3900767aba00 M
On Sun, Aug 14, 2011 at 6:39 AM, Steve Bennett wrote:
> I pushed a change to jimtcl git which will use Sleep() if usleep() is
> unavailable on mingw32.
Now building OpenOCD with latest jimtcl with mingw32 works for me. Thank you!
Jie
___
Openocd-develo
On Fri, Aug 12, 2011 at 10:15 PM, Xiaofan Chen wrote:
> On Sat, Aug 13, 2011 at 9:38 AM, Jie Zhang wrote:
>> On Fri, Aug 12, 2011 at 9:27 PM, Xiaofan Chen wrote:
>>> On Sat, Aug 13, 2011 at 9:00 AM, Jie Zhang wrote:
>>>> Another option is to drop mingw32 and requ
On Fri, Aug 12, 2011 at 9:27 PM, Xiaofan Chen wrote:
> On Sat, Aug 13, 2011 at 9:00 AM, Jie Zhang wrote:
>> Another option is to drop mingw32 and require mingw-w64.
>>
>
> Do not do that. usleep is fine with later version of MinGW.org
> Win32API package.
>
> This
Forgot to CC the list.
On Fri, Aug 12, 2011 at 7:49 PM, Steve Bennett wrote:
> On 13/08/2011, at 7:26 AM, Jie Zhang wrote:
>
>> On Fri, Aug 12, 2011 at 5:19 PM, Steve Bennett
>> wrote:
>>> On 13/08/2011, at 6:41 AM, Jie Zhang wrote:
>>>
>>>
On Fri, Aug 12, 2011 at 5:19 PM, Steve Bennett wrote:
> On 13/08/2011, at 6:41 AM, Jie Zhang wrote:
>
>> The current HEAD cannot build with mingw32
>>
>> libtool: link: i586-mingw32msvc-gcc -std=gnu99 -g -O2
>> -I/home/jie/installs/openocd/include -D__USE_MING
The current HEAD cannot build with mingw32
libtool: link: i586-mingw32msvc-gcc -std=gnu99 -g -O2
-I/home/jie/installs/openocd/include -D__USE_MINGW_ANSI_STDIO -Wall
-Wstrict-prototypes -Wformat-security -Wshadow -Wextra
-Wno-unused-parameter -Wbad-function-cast -Wcast-align
-Wredundant-decls -Werr
On Thu, Aug 11, 2011 at 4:47 PM, Spencer Oliver wrote:
> On 01/08/2011 10:05, Spencer Oliver wrote:
>>
>> On 29 July 2011 22:23, Andreas Fritiofson
>> wrote:
Another fix would be not trying to print the status as a numeric
value. We can print it as an error message, so we don't nee
On Wed, Aug 10, 2011 at 2:53 PM, Øyvind Harboe wrote:
>>> Then when I pull to push to the repository, then without rebasing on
>>> my end I will not get a linear history.
>> this is the key point linear history make is lose the information on which
>> commit the code was bsed and tested before the
On Wed, Aug 10, 2011 at 10:13 PM, Steve Bennett wrote:
> Please try the attached.
> If there are no problems we can ask for it to me merged.
>
I just tried your patch. It works for me. Thank you!
Jie
___
Openocd-development mailing list
Openocd-develop
On Wed, Aug 10, 2011 at 8:27 PM, Steve Bennett wrote:
> On 09/08/2011, at 11:18 PM, Jie Zhang wrote:
>
>> Hi,
>>
>> Since we are in merge window now, how about merge this patch to
>> replace script with source:
>>
>> https://lists.berlios.de/pipermail
Hi,
I believe that pxref is useless. Please review and merge if OK. Thank you!
Jie
>From a78298da35c10a45136fdae0caede2860d30bbf5 Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Wed, 10 Aug 2011 15:32:09 -0400
Subject: [PATCH] remove useless pxref to SMP subsection
---
doc/openocd.texi |
On Wed, Aug 10, 2011 at 11:00 AM, Øyvind Harboe wrote:
> On Wed, Aug 10, 2011 at 4:21 PM, Jie Zhang wrote:
>> Hi,
>>
>> Just to make sure that we still do code review with "git pull", right?
>> The developer still need to post all his/her patches for review
Hi,
Just to make sure that we still do code review with "git pull", right?
The developer still need to post all his/her patches for review before
he/she asks for pull, right?
Regards,
Jie
___
Openocd-development mailing list
Openocd-development@lists.be
On Wed, Aug 10, 2011 at 9:29 AM, Xiaofan Chen wrote:
> On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver wrote:
>> Just tested building native windoze under cygwin and working fine here.
>> I used the release tarball and the following configure line:
>> ./configure --build=i686-pc-cygwin --host=i68
Hi,
Since we are in merge window now, how about merge this patch to
replace script with source:
https://lists.berlios.de/pipermail/openocd-development/2011-July/020370.html
If there is any issue, we still have enough time to revert this change.
Regards,
Jie
_
On Tue, Aug 9, 2011 at 7:52 AM, Vit Mares wrote:
> Attempt to build 0.5.0 with MinGW on Windows XP failed when running configure.
> Release 0.4.0 configured and built without problems.
I downloaded 0.5.0 and built it with mingw-w64 on Debian testing. The
build was successful. But I didn't try the
On Mon, Aug 1, 2011 at 5:05 AM, Spencer Oliver wrote:
> On 29 July 2011 22:23, Andreas Fritiofson
> wrote:
>>> Another fix would be not trying to print the status as a numeric
>>> value. We can print it as an error message, so we don't need to handle
>>> this tricky situation. Like
>>>
>>>
On Sat, Jul 30, 2011 at 5:48 PM, B wrote:
> Using Open On-Chip Debugger 0.5.0-dev-00948-gd4cd6f0 (2011-07-30-15:55)
>
> LM3S3N26-C5 is not detected as a Tempest device and so uses the sysresetreq
> in place of the needed vectreset in stellaris.cfg.
>
> The device class appears to be set by:
>
> se
On Mon, Aug 1, 2011 at 10:18 AM, Spencer Oliver wrote:
> On 29 July 2011 16:54, Jie Zhang wrote:
>> On Fri, Jul 29, 2011 at 11:41 AM, Spencer Oliver
>> wrote:
>>> On 29 July 2011 15:32, Jie Zhang wrote:
>>>> I happened to find that two previous fixes for se
On Fri, Jun 24, 2011 at 3:14 PM, Jie Zhang wrote:
> On Mon, Jun 20, 2011 at 6:50 AM, Steve Bennett wrote:
>> The default is -Werror, so warnings become errors
>> and stop the build.
>> Might be better to simply #define FT_STATUS instead.
>>
>> -
On Thu, Jun 23, 2011 at 5:43 PM, Steve Bennett wrote:
> Then perhaps this is what you are after.
> I'm not sure if it is any more correct, since FT_STATUS
> is ULONG which is unsigned int (!), not uint32_t
>
I happened to find a slightly revised version of this patch was merged
recently. But it wi
On Fri, Jul 29, 2011 at 11:41 AM, Spencer Oliver wrote:
> On 29 July 2011 15:32, Jie Zhang wrote:
>> I happened to find that two previous fixes for set-but-not-used
>> warnings are not correct or not good. This patch should be an
>> improvement. Please review and merge if
On Fri, Jul 29, 2011 at 11:24 AM, Jie Zhang wrote:
> On Fri, Jul 29, 2011 at 8:16 AM, Steve Bennett wrote:
>> Makes sense to me to change it to:
>> proc script {filename} {
>> uplevel #0 source [find $filename]
>> }
>>
> The attached patch removes &quo
401c2 Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Fri, 29 Jul 2011 10:45:10 -0400
Subject: [PATCH] remove script command
---
src/helper/configuration.c |2 +-
src/helper/options.c |2 +-
src/helper/startup.tcl |7 ---
3 files changed, 2 insertions(+), 9 deletions(-)
I happened to find that two previous fixes for set-but-not-used
warnings are not correct or not good. This patch should be an
improvement. Please review and merge if good.
Regards,
Jie
diff --git a/src/target/etb.c b/src/target/etb.c
index 3cb2254..974ab2b 100644
--- a/src/target/etb.c
+++ b/src/
On Fri, Jul 29, 2011 at 7:12 AM, Øyvind Harboe wrote:
> Its historical. Perhaps it should be this way? Perhaps ot is better to pass
> args as args to procs rathr than global variables? Perhaps we should retire
> "script"?
>
It's really historical. It was in the first commit in the OpenOCD git
repo
On Fri, Jul 29, 2011 at 7:34 AM, Spencer Oliver wrote:
> On 29 July 2011 11:45, Jie Zhang wrote:
>> Hi,
>>
>> OpenOCD uses script command to execute config file passed through "-f"
>> option. script command is defined as a function
>>
>> proc scr
ass
> args as args to procs rathr than global variables? Perhaps we should retire
> "script"?
>
> On Jul 29, 2011 12:45 PM, "Jie Zhang" wrote:
>> Hi,
>>
>> OpenOCD uses script command to execute config file passed through "-f"
>> optio
Hi,
OpenOCD uses script command to execute config file passed through "-f"
option. script command is defined as a function
proc script {filename} {
source [find $filename]
}
Thus when executing the config file, global variables defined in that
config file is not global any more. If I def
On Fri, Jul 29, 2011 at 12:10 AM, Steve Bennett wrote:
> On 29/07/2011, at 2:06 PM, Steve Bennett wrote:
>
>> On 29/07/2011, at 1:40 PM, Jie Zhang wrote:
>>
>>> Hi,
>>>
>>> Where is the "script" command defined? I greped in jimtcl and op
Hi,
Where is the "script" command defined? I greped in jimtcl and openocd
source code, but could not find it. Thank you!
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-deve
The subject explains this patch.
Jie
From 26f44455cf1db6f2efb8531f5476ad2845e47f13 Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Thu, 21 Jul 2011 11:29:20 -0400
Subject: [PATCH] remove doc on the deprecated '-p' option
---
doc/openocd.texi |2 --
1 files changed, 0 insert
The commit log explains this patch.
Jie
From 00597ea44a60e70a86ef989acfb8193c15de811a Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Thu, 21 Jul 2011 11:16:50 -0400
Subject: [PATCH] Update doc about Jim since it's not a single .C file and a
single .H file any more
---
doc/openocd.texi |
I noticed that:
On Mon, Jul 18, 2011 at 10:41 PM, Brian Hutchinson wrote:
> GNU gdb (GDB) 7.1
> This GDB was configured as "i686-pc-linux-gnu".
and
> hutch@neo:~/openocd/openocd/src$ file ./openocd
> ./openocd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
So gdb is for i686-pc-linux-gn
On Thu, Jul 14, 2011 at 12:07 PM, Jie Zhang wrote:
> On Thu, Jul 14, 2011 at 6:17 AM, Steve Bennett wrote:
>> On 14/07/2011, at 7:19 PM, Spencer Oliver wrote:
>>> This is why i mentioned before about adding a configure option to
>>> jimtcl, something like --noinstall
&
On Thu, Jul 14, 2011 at 6:17 AM, Steve Bennett wrote:
> On 14/07/2011, at 7:19 PM, Spencer Oliver wrote:
>> This is why i mentioned before about adding a configure option to
>> jimtcl, something like --noinstall
>
> It seems weird to have a configure option which causes 'make install'
> to not ins
On Thu, Jul 14, 2011 at 10:57 AM, Spencer Oliver wrote:
> On 14 July 2011 15:01, Jie Zhang wrote:
>> On Thu, Jul 14, 2011 at 8:57 AM, Spencer Oliver wrote:
>>>> I tell a lie, just discovered the noinst_SUBDIRS and that seems todo
>>>> what we want
>>
On Thu, Jul 14, 2011 at 8:57 AM, Spencer Oliver wrote:
>> I tell a lie, just discovered the noinst_SUBDIRS and that seems todo
>> what we want
>>
>
> Spoke to soon, does not work.
> So at the moment i am out of ideas
>
It works for me. With the attached patch, "make install" does not
install jimtc
On Thu, Jul 14, 2011 at 8:58 AM, Tomek CEDRO wrote:
> Hello!
>
> Sorry for cross-posting but this somehow touches both applications.
> LibSWD is a standalone library that can generate SWD operations, then
> flush them into device driver. This driver (some function set) is
> application specific, s
On Wed, Jul 13, 2011 at 8:19 AM, Xiaofan Chen wrote:
> I have seen some warnings when doing bootstrap. I am
> not so sure if this is a bug with Ubuntu autotools or
> with configure.in.
>
> The same problem exists in Ubuntu 10.10 and 10.04.
>
> mcuee@Ubuntu:~/Desktop/build/openocd/openocd$ ./bootst
On Wed, Jul 6, 2011 at 3:21 PM, Drasko DRASKOVIC
wrote:
> I thought that there might be a method of leaving this stuff into the
> code but preceding it wit some macro NOT_USED, or something...
>
You can use the following GCC attribute for your purpose.
unused
This attribute, attached to a fun
On Tue, Jun 28, 2011 at 1:56 PM, Øyvind Harboe wrote:
> On Tue, Jun 28, 2011 at 7:30 PM, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>> On 19:39 Tue 28 Jun , Øyvind Harboe wrote:
>>> > but now all the maintainer will have their own fork/repository
>>> > as done in the kernel
>>>
>>> Right. And
On Tue, Jun 28, 2011 at 12:26 PM, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> Changelog
>
What is this change against? Some commit on master?
Regards,
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/m
On Mon, Jun 20, 2011 at 6:50 AM, Steve Bennett wrote:
> The default is -Werror, so warnings become errors
> and stop the build.
> Might be better to simply #define FT_STATUS instead.
>
> - LOG_ERROR("FT_Write returned: %lu", status);
> + LOG_ERROR("FT_Write returned: %l
On Sat, Jun 18, 2011 at 4:36 AM, Tomek CEDRO wrote:
> On Thu, Jun 16, 2011 at 9:42 PM, Andreas Fritiofson
> wrote:
>> a ? : b is equivalent to a ? a : b, unless evaluating a has side-effects or
>> if a is volatile, since it's only evaluated once in the former case and
>> twice in the latter.
>
>
On Wed, May 25, 2011 at 6:32 PM, Kevin Kiningham wrote:
> adapter_khz_to_speed wasn't changing the speed variable passed to it if the
> jtag interface wasn't set up. Otherwise, if adapter_khz was called before
> openocd was done initializing, openocd would report a speed different than
> it was ac
Hi Rosa,
On Tue, May 17, 2011 at 10:58 PM, Rodrigo Rosa wrote:
> - flashing speed: currently i flush the jtag queue all the time, to
> make coding easy. flashing 4KB currently takes about 45secs, which is
> not acceptable. the algorithm i'm running requires openocd to check a
> register (written
Hi Alex,
On Tue, May 17, 2011 at 8:11 PM, Austin, Alex
wrote:
> I am attempting to use OpenOCD with a cellular chipset with an ARM11 and an
> ARM7+DSP core. I can access it with the Lauterbach debugger, but I find the
> interface very difficult to use and would prefer OpenOCD.
>
> It looks like s
On Wed, May 18, 2011 at 1:17 AM, Øyvind Harboe wrote:
> Are you still comfortable with this patch?
>
Yes. I think this patch provides targets freedom to choose when and
how to read registers. And it should not affect existing targets.
> Any objections?
>
> Anyone did any testing on other targets?
In startup.tcl, ocd_process_reset_inner calls init_reset with the
following comment:
# Use TRST or TMS/TCK operations to reset all the tap controllers.
# TAP reset events get reported; they might enable some taps.
So it seems init_reset should only reset TAP controllers.
After that, ocd_proces
On Tue, May 3, 2011 at 4:48 PM, Mathias K. wrote:
> Am 03.05.2011 22:12, schrieb Jie Zhang:
>> I'm not familiar with ARM targets. So I'm not very sure. My guess is
>> this can also improve performance on ARM targets but they needs be
>> adapted to this lazy read u
On Tue, May 3, 2011 at 4:18 PM, Mathias K. wrote:
> I think gdb will get the register list and then, maybe depending on used
> debug application, all
> register values.
>
This is true for recent GDB versions. Unfortunately, we are still
using an old version, 6.6, which uses packet 'p' to read sin
On Tue, May 3, 2011 at 4:05 PM, Øyvind Harboe wrote:
> Start with a smoketest.
>
> Would this improve performance on ARM targets you think?
>
I'm not familiar with ARM targets. So I'm not very sure. My guess is
this can also improve performance on ARM targets but they needs be
adapted to this lazy
On Tue, May 3, 2011 at 4:03 PM, Øyvind Harboe wrote:
> Merged.
>
> Thanks!
>
Thank you!
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Tue, May 3, 2011 at 3:30 PM, Øyvind Harboe wrote:
> Which target are you working on btw?
>
I'm working on Blackfin.
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-develo
Hi Øyvind,
On Tue, May 3, 2011 at 3:30 PM, Øyvind Harboe wrote:
> I would like to have this patch regression tested against ARM targets
> before I commit it.
>
Could you or someone else help me regression test it on ARM targets?
Is there any documentation about regression test? I may want to run
read the register if it's invalid.
This patch makes gdb_get_registers_packet and gdb_get_register_packet
do the same thing.
This patch should not affect existing targets.
Regards,
Jie
From 4fddaa909ac705a8bd5777a7121164f9aa1309b6 Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Tue, 3 May 2
This is an trivial patch. I found this when looking at AVR32 target code.
Jie
From 30dc90988489f91c5599ee5af515d0574d4f7577 Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Tue, 3 May 2011 14:43:22 -0400
Subject: [PATCH] Remove useless MIPS code in avr32_ap7k.c.
---
src/target/avr32_ap7k.c
On Mon, May 2, 2011 at 3:52 PM, Michael Trensch wrote:
> I often use openOCD and GDB/Insight to attach to a running target that I
> don't want to halt, or even cannot halt it during my debugging session.
> I just want to take to see the call stack and program counter when it
> crashes or when it r
On Mon, May 2, 2011 at 3:35 PM, Øyvind Harboe wrote:
> After connecting GDB to OpenOCD, you need to issue a "stepi" to sync
> GDB and OpenOCD.
>
This is not documented in the manual.
> The advantage of this approach is (amongst many other things) that
> attaching to the target does *nothing*. Via
On Mon, May 2, 2011 at 3:31 PM, Øyvind Harboe wrote:
>
> Short story: creates other nasty problems.
>
> You can easily add a "monitor halt" + "stepi" to your gdb init
> sequence.
>
Thank you for your reply. But what are the other nasty problems?
Jie
_
When GDB connects to OpenOCD, OpenOCD does not halt the target by default.
To halt the target, users have to add "halt" to gdb-attach event hook in
target configuration file or type the command "monitor halt" from GDB
command line interface. The latter method caused some confusion for me.
Since Op
u need to restore the context. This is why the target
> registers never read again
> if the target already halted.
>
>
> Am 02.05.2011 18:22, schrieb Jie Zhang:
> > Thank you for your reply!
> >
> > I'm adding a new target to OpenOCD. But I think all existing targets i
t; Regards,
>
> Mathias
>
> Am 02.05.2011 18:06, schrieb Jie Zhang:
> > Hi,
> >
> > I encountered an issue when using OpenOCD with GDB. After GDB connects to
> OpenOCD and halt the
> > target, "info reg" command returns all zeros for all registers.
Hi,
I encountered an issue when using OpenOCD with GDB. After GDB connects to
OpenOCD and halt the target, "info reg" command returns all zeros for all
registers. I took a look at the related code and found that when GDB
requests register values from OpenOCD, OpenOCD does not read register from
ta
92 matches
Mail list logo
