Re: [Openocd-development] New patch to review for openocd: 7067428 Revert "Evaluate 'script' in the global scope"
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 cannot comment on Gerrit... > > The discussion - > https://lists.berlios.de/pipermail/openocd-development/2011-August/020462.html > - not easy to find (links to list are links to NEW and EMPTY sourceforge > forum) so I had to google that up. There is absolutely no discussion or > reasoning there, this change was introduced "just because" and based on "why > not?". > > Or maybe there's another discussion I cannot find. > This is the first email of the discussion: https://lists.berlios.de/pipermail/openocd-development/2011-July/020359.html Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jim Tcl problems
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 > git clean -f -x -d > ./bootstrap > ./configure --enable-dummy --enable-maintainer-mode > I have no jim-tclcompat.c nor jim-glob.c in my jimtcl/ . Maybe your jimtcl is not new enough? Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jim Tcl problems
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 > reference to `Jim_Eval_Named' > libjim.a(jim-glob.o): In function `Jim_globInit': > /home/oyvind/workspace/openocd/jimtcl/jim-glob.c:7: undefined > reference to `Jim_Eval_Named' > libjim.a(jim-tclcompat.o): In function `Jim_tclcompatInit': > /home/oyvind/workspace/openocd/jimtcl/jim-tclcompat.c:7: undefined > reference to `Jim_Eval_Named' > collect2: ld returned 1 exit status > make[2]: *** [jimsh] Error 1 > rm _jim-tclcompat.c _jim-glob.c _jim-stdlib.c > make[2]: Leaving directory `/home/oyvind/workspace/openocd/jimtcl' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/oyvind/workspace/openocd' > make: *** [all] Error 2 > oyvind@titan:~/workspace/openocd$ git status > # Not currently on any branch. > nothing to commit (working directory clean) > 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. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Remove "qP" from rtos code?
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 GDB > releases since 5.0 will not send out qP packet if the stub supports > qThreadExtraInfo. So I think it's safe for OpenOCD to remove qP > support and only keep qThreadExtraInfo. This will make code clean and > reduce maintenance effort. > > Regards, > Jie > > On Thu, Aug 25, 2011 at 8:50 PM, Evan Hunter wrote: >> Backward compatibility is the reason - >> When I was testing with GDB+eclipse 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, >> >> Evan >> >> >> >> >> Quoting Jie Zhang : >> >>> 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 >>> Openocd-development@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/openocd-development >>> >> >> >> >> > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style plan
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. > > Resources: > > Does anyone want to do this? > I think first is to set a date for the conversion so everyone can prepare for this conversion. Item a is everyone's job. If he/she does not want to reformat all his/her patches after conversion, he/she should push out the patches to be merged before the conversion date. I can do Item b and c if we set the conversion date to the end of this year. I think I should have some spare time at that time. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
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 make a plan to do the coding style switch? We cannot do now immediately since it will break all patches in people's local trees. We need to set a roughly date so people can prepare for it. The end of this year or the beginning of the next year will be a good point time for me. I think I will have already pushed out all my patches at that time. And at that time, people will be in Christmas and New year holidays. There might be less development activities. So the impact will be likely less than other times of a year. What's your thought? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
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. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 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 be amended to the patch > sequence. > > Thus maintainers would not have to check the patches and give > feedback, this would happen before the patches were posted. > My experience is such a script is better than nothing, but it cannot check everything in coding style and developer ofter forget to check the patch with it. I can volunteer to review patch for coding style. But before that we need to set the rule about those issues I raised, since current documentation does not say anything about them. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Errors encountered programming an FPGA using 13MB SVF file
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 ftdi driver. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
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 merged. >> >> And there are still something missing on >> http://openocd.berlios.de/doc/doxygen/html/stylec.html , like >> >> * how to deal with long list of arguments, which cannot fix in one line? >> * how to place { }? I saw >> >> if (...) { >> } else { >> } >> >> if (...) >> { >> } >> else >> { >> } >> >> * should there be a white space after ( and before )? I saw code both. >> >> >> > If you change to much the diff files can get big. I don't propose to fix all coding style issue right now. I propose to do coding style check when reviewing patch from now. At some appropriate point in future, we can fix coding style issues at once. > I do agree with you that your suggestion is more appropriate but you will > find people who prefer the other approach. > Personnally I just use the beautify in slickedit to fix that. > I'm not used to the current coding style of OpenOCD. I'm more used to GNU coding style. But I can use the established coding style in OpenOCD without a problem. A consistent coding style is important for the readability and maintenance of software. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Remove "qP" from rtos code?
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 GDB releases since 5.0 will not send out qP packet if the stub supports qThreadExtraInfo. So I think it's safe for OpenOCD to remove qP support and only keep qThreadExtraInfo. This will make code clean and reduce maintenance effort. Regards, Jie On Thu, Aug 25, 2011 at 8:50 PM, Evan Hunter wrote: > Backward compatibility is the reason - > When I was testing with GDB+eclipse 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, > > Evan > > > > > Quoting Jie Zhang : > >> 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 >> Openocd-development@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/openocd-development >> > > > > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Coding style
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 long list of arguments, which cannot fix in one line? * how to place { }? I saw if (...) { } else { } if (...) { } else { } * should there be a white space after ( and before )? I saw code both. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] threadid_t
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/openocd-development
[Openocd-development] Remove "qP" from rtos code?
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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Next release
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 to a state where the community is happy to take responsibility > for it. > > Other things? > I'm working on adding Blackfin support. But I'm not sure if it will be ready before the next release. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Remove target argument from gdb packet handling functions
On Wed, Aug 24, 2011 at 12:53 AM, Øyvind Harboe wrote: > I'm OK with this. > > Perhaps make a tiny static fn for: > > + struct gdb_service *gdb_service = connection->service->priv; > + struct target *target = gdb_service->target; > I think this is 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] remove target argument from gdb packet handling functions --- src/rtos/rtos.c |8 +++- src/rtos/rtos.h |4 +- src/server/gdb_server.c | 106 -- src/server/gdb_server.h |6 +++ src/target/smp.c|6 ++- src/target/smp.h|4 +- 6 files changed, 66 insertions(+), 68 deletions(-) diff --git a/src/rtos/rtos.c b/src/rtos/rtos.c index 263795c..74e8724 100644 --- a/src/rtos/rtos.c +++ b/src/rtos/rtos.c @@ -128,8 +128,10 @@ int rtos_create(Jim_GetOptInfo *goi, struct target * target) -int gdb_thread_packet(struct connection *connection, struct target *target, char *packet, int packet_size) +int gdb_thread_packet(struct connection *connection, char *packet, int packet_size) { + struct target *target = get_target_from_connection(connection); + if (strstr(packet, "qP")) { #define TAG_THREADID 1 /* Echo the thread identifier */ @@ -501,8 +503,10 @@ int gdb_thread_packet(struct connection *connection, struct target *target, char return GDB_THREAD_PACKET_NOT_CONSUMED; } -int rtos_get_gdb_reg_list(struct connection *connection, struct target *target, struct reg **reg_list[], int *reg_list_size) +int rtos_get_gdb_reg_list(struct connection *connection, struct reg **reg_list[], int *reg_list_size) { + struct target *target = get_target_from_connection(connection); + if ( ( target->rtos != NULL ) && ( current_threadid != -1 ) && ( current_threadid != 0 ) && diff --git a/src/rtos/rtos.h b/src/rtos/rtos.h index a6378c6..1a73bd7 100644 --- a/src/rtos/rtos.h +++ b/src/rtos/rtos.h @@ -99,8 +99,8 @@ struct rtos_register_stacking int rtos_create(Jim_GetOptInfo *goi, struct target * target); int rtos_generic_stack_read( struct target * target, const struct rtos_register_stacking* stacking, int64_t stack_ptr, char ** hex_reg_list ); int rtos_try_next( struct target * target ); -int gdb_thread_packet(struct connection *connection, struct target *target, char *packet, int packet_size); -int rtos_get_gdb_reg_list(struct connection *connection, struct target *target, struct reg **reg_list[], int *reg_list_size); +int gdb_thread_packet(struct connection *connection, char *packet, int packet_size); +int rtos_get_gdb_reg_list(struct connection *connection, struct reg **reg_list[], int *reg_list_size); int rtos_update_threads( struct target *target ); #endif // RTOS_H diff --git a/src/server/gdb_server.c b/src/server/gdb_server.c index b6921ff..5eb6cac 100644 --- a/src/server/gdb_server.c +++ b/src/server/gdb_server.c @@ -944,8 +944,9 @@ static void gdb_send_error(struct connection *connection, uint8_t the_error) } static int gdb_last_signal_packet(struct connection *connection, - struct target *target, char* packet, int packet_size) + char* packet, int packet_size) { + struct target *target = get_target_from_connection(connection); char sig_reply[4]; int signal_var; @@ -1029,8 +1030,9 @@ static void gdb_target_to_reg(struct target *target, } static int gdb_get_registers_packet(struct connection *connection, - struct target *target, char* packet, int packet_size) + char* packet, int packet_size) { + struct target *target = get_target_from_connection(connection); struct reg **reg_list; int reg_list_size; int retval; @@ -1044,7 +1046,7 @@ static int gdb_get_registers_packet(struct connection *connection, #endif if ( ( target->rtos != NULL ) && - ( ERROR_FAIL != rtos_get_gdb_reg_list( connection, target, ®_list, ®_list_size) ) ) + ( ERROR_FAIL != rtos_get_gdb_reg_list( connection, ®_list, ®_list_size) ) ) { return ERROR_OK; } @@ -1088,8 +1090,9 @@ static int gdb_get_registers_packet(struct connection *connection, } static int gdb_set_registers_packet(struct connection *connection, - struct target *target, char *packet, int packet_size) + char *packet, int packet_size) { + struct target *target = get_target_from_connection(connection); int i; struct reg **reg_list; int reg_list_size; @@ -1147,8 +1150,9 @@ static int gdb_set_registers_packet(struct connection *connection, } static int gdb_get_register_packet(struct connection *connection, - struct target *target, char *packet, int packet_size) + char *packet, int packet_size) { + struct target *target = get_target_from_connection(connection); char *reg_packet; int r
[Openocd-development] [PATCH] Remove target argument from gdb packet handling functions
Hi, In OpenOCD, all gdb packet handling functions look like: gdb_xxx_packet(connection, target, packet, packet_size); I'm wondering if we can remove target from the argument list and just calculate it from connection in each handling function. The patch is attached. I like this patch since I think the code is clearer with it and the big switch in gdb_input_inner will be more generic. The cons is the code size will be a little larger, on x86_64, it's from 1295167B to 1295343B. But I think it's not a real issue. What's your opinion? 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/gdb_server.c | 118 +++ src/target/smp.c|8 ++- src/target/smp.h|4 +- 5 files changed, 76 insertions(+), 68 deletions(-) diff --git a/src/rtos/rtos.c b/src/rtos/rtos.c index 263795c..12a944f 100644 --- a/src/rtos/rtos.c +++ b/src/rtos/rtos.c @@ -128,8 +128,11 @@ int rtos_create(Jim_GetOptInfo *goi, struct target * target) -int gdb_thread_packet(struct connection *connection, struct target *target, char *packet, int packet_size) +int gdb_thread_packet(struct connection *connection, char *packet, int packet_size) { + struct gdb_service *gdb_service = connection->service->priv; + struct target *target = gdb_service->target; + if (strstr(packet, "qP")) { #define TAG_THREADID 1 /* Echo the thread identifier */ @@ -501,8 +504,11 @@ int gdb_thread_packet(struct connection *connection, struct target *target, char return GDB_THREAD_PACKET_NOT_CONSUMED; } -int rtos_get_gdb_reg_list(struct connection *connection, struct target *target, struct reg **reg_list[], int *reg_list_size) +int rtos_get_gdb_reg_list(struct connection *connection, struct reg **reg_list[], int *reg_list_size) { + struct gdb_service *gdb_service = connection->service->priv; + struct target *target = gdb_service->target; + if ( ( target->rtos != NULL ) && ( current_threadid != -1 ) && ( current_threadid != 0 ) && diff --git a/src/rtos/rtos.h b/src/rtos/rtos.h index a6378c6..1a73bd7 100644 --- a/src/rtos/rtos.h +++ b/src/rtos/rtos.h @@ -99,8 +99,8 @@ struct rtos_register_stacking int rtos_create(Jim_GetOptInfo *goi, struct target * target); int rtos_generic_stack_read( struct target * target, const struct rtos_register_stacking* stacking, int64_t stack_ptr, char ** hex_reg_list ); int rtos_try_next( struct target * target ); -int gdb_thread_packet(struct connection *connection, struct target *target, char *packet, int packet_size); -int rtos_get_gdb_reg_list(struct connection *connection, struct target *target, struct reg **reg_list[], int *reg_list_size); +int gdb_thread_packet(struct connection *connection, char *packet, int packet_size); +int rtos_get_gdb_reg_list(struct connection *connection, struct reg **reg_list[], int *reg_list_size); int rtos_update_threads( struct target *target ); #endif // RTOS_H diff --git a/src/server/gdb_server.c b/src/server/gdb_server.c index b6921ff..3509b93 100644 --- a/src/server/gdb_server.c +++ b/src/server/gdb_server.c @@ -944,8 +944,10 @@ static void gdb_send_error(struct connection *connection, uint8_t the_error) } static int gdb_last_signal_packet(struct connection *connection, - struct target *target, char* packet, int packet_size) + char* packet, int packet_size) { + struct gdb_service *gdb_service = connection->service->priv; + struct target *target = gdb_service->target; char sig_reply[4]; int signal_var; @@ -1029,8 +1031,10 @@ static void gdb_target_to_reg(struct target *target, } static int gdb_get_registers_packet(struct connection *connection, - struct target *target, char* packet, int packet_size) + char* packet, int packet_size) { + struct gdb_service *gdb_service = connection->service->priv; + struct target *target = gdb_service->target; struct reg **reg_list; int reg_list_size; int retval; @@ -1044,7 +1048,7 @@ static int gdb_get_registers_packet(struct connection *connection, #endif if ( ( target->rtos != NULL ) && - ( ERROR_FAIL != rtos_get_gdb_reg_list( connection, target, ®_list, ®_list_size) ) ) + ( ERROR_FAIL != rtos_get_gdb_reg_list( connection, ®_list, ®_list_size) ) ) { return ERROR_OK; } @@ -1088,8 +1092,10 @@ static int gdb_get_registers_packet(struct connection *connection, } static int gdb_set_registers_packet(struct connection *connection, - struct target *target, char *packet, int packet_size) + char *packet, int packet_size) { + struct gdb_service *gdb_service = connection->service->priv; + struct target *target = gdb_service->target; int i; struct reg **reg_list; int reg_list
Re: [Openocd-development] target number
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 purpose. > > Perhaps retire target number from tcl usage and clean it up so it can > be used internally from GDB for your hw thread purposes? > As long as no two targets has the same number and the number does not change during the life of target, it will be good. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] target number
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 need something as thread id. target_number is good for this purpose. Does keeping target_number hurt? Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] target number
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Remove white space before TAB
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 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/target/Makefile.am b/src/target/Makefile.am index 27ad054..9f7e5e9 100644 --- a/src/target/Makefile.am +++ b/src/target/Makefile.am @@ -84,7 +84,7 @@ ARM_DEBUG_SRC = \ arm_simulator.c \ arm_semihosting.c \ arm_adi_v5.c \ - adi_v5_jtag.c \ + adi_v5_jtag.c \ adi_v5_swd.c \ embeddedice.c \ trace.c \ -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] A fix (was Re: Git revision string missing from banner)
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 a regular file. my reason is: We decide if we are building for release or not by the existence of guess-rev.sh, not by the existence of an executable guess-rev.sh. So 1. guess-rev.sh exists and is executable: checking regular file is same as checking executable file. 2. guess-rev.sh does not exist: checking regular file is same as checking executable file. 3. guess-rev.sh exists but is not executable: there must be something wrong. If we check regular file, user will be given an error when guess-rev.sh is going to be executed on compiler time. If we check executable file, building for release is assumed and user will notice it only in run time. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Add a configure option to enable/disable rtos support
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 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 as a thread in rtos. > > eCos is an RTOS that supports multiple CPUs. > > I think it is reasonable to enable/disable threads as a way to choose between > CPUs and a way to choose between RTOS threads, but I think that choice > should happen during configuration runtime in the scripts and not at > build time. > Thanks for your comment. Runtime is surely better than configure time. But it will also be more difficult, thus need more time, to implement. I will try and see if I can do it in my schedule. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Rename configure.in as configure.ac
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] rename configure.in as configure.ac --- configure.in => configure.ac |0 1 files changed, 0 insertions(+), 0 deletions(-) rename configure.in => configure.ac (100%) diff --git a/configure.in b/configure.ac similarity index 100% rename from configure.in rename to configure.ac -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Add a configure option to enable/disable rtos support
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 as a thread in rtos. Btw, my memory might be wrong. I didn't find the supposed configure option which could be used to enable/disable rtos support. It seems I have to add one. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Add a configure option to enable/disable rtos support
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 conflict with rtos, which also uses threads. So I'm considering adding back the rtos enabling configure option. I will also add a new option to enable/disable multi-thread for multi-core and make these two options exclusive to each other. Do you think this is a good plan? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] A fix (was Re: Git revision string missing from banner)
On Mon, Aug 15, 2011 at 9:35 AM, Spencer Oliver wrote: > On 15 August 2011 14:22, Eric Wetzel wrote: >> if test $cross_compiling = no; then >> # guess-rev.sh only exists in the repository, not in the released archives >> AC_CHECK_FILE("$srcdir/guess-rev.sh", has_guess_rev=yes, has_guess_rev=no) >> >> We automatically assume that if we are cross-compiling that we are >> building a release. This section was last modified in July 2009, back >> in the SVN days, but the commit is here: >> http://repo.or.cz/w/openocd.git/commitdiff/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 Mon Sep 17 00:00:00 2001 From: Jie Zhang Date: Mon, 15 Aug 2011 10:52:11 -0400 Subject: [PATCH] show git commit number even when cross-compiling AC_CHECK_FILE will die when cross-compiling. So don't use it to test the existence of guess-rev.sh. --- configure.in | 16 +--- 1 files changed, 5 insertions(+), 11 deletions(-) diff --git a/configure.in b/configure.in index dfa1e8f..3c0056c 100644 --- a/configure.in +++ b/configure.in @@ -143,20 +143,14 @@ is_mingw=no is_win32=no is_darwin=no -if test $cross_compiling = no; then - # guess-rev.sh only exists in the repository, not in the released archives - AC_CHECK_FILE("$srcdir/guess-rev.sh", has_guess_rev=yes, has_guess_rev=no) - - AC_MSG_CHECKING([whether to build a release]) - if test $has_guess_rev = no; then -build_release=yes - else -build_release=no - fi - AC_MSG_RESULT($build_release) +# guess-rev.sh only exists in the repository, not in the released archives +AC_MSG_CHECKING([whether to build a release]) +if test -f $srcdir/guess-rev.sh ; then + build_release=no else build_release=yes fi +AC_MSG_RESULT($build_release) # We are not *ALWAYS* being installed in the standard place. # We may be installed in a "tool-build" specific location. -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build error with mingw32
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-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build error with mingw32
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 require mingw-w64. >>>> >>> >>> Do not do that. usleep is fine with later version of MinGW.org >>> Win32API package. >>> >>> This is probably because you have a very old version of MinGW >>> and MinGW Win32-API. Seems to be a problem with Debian. >>> http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/RuntimeLibrary/Win32-API/ >>> >>> Debian seems to ship a 3-year old MinGW Win32-API. >>> http://packages.debian.org/search?searchon=sourcenames&keywords=mingw32 >>> >> Hmm, good point. I have written an email to the mingw32-runtime >> package maintainer of Debian to see if he has any plan to update it to >> the latest version. > > BTW, there are other problems with the Linux MinGW packages > in Debian/Ubuntu. > > This is one of them which does not affect C based programs > like OpenOCD but it will affect C++ based programs. > http://comments.gmane.org/gmane.comp.gnu.mingw.user/36693 > > Basically MinGW.org native compiler and the Cygwin > i686-pc-ming32 cross compiler are built with --disable-sjlj-exceptions > whereas many Linux MinGW cross compilers are built with > a default option which is --enable-sjlj-exceptions. That is the > case with MinGW package inside Ubuntu 11.04. > In GCC, the default is --disable-sjlj-exceptions. So I'm confused. In Debian testing, mingw32 is configured with --enable-sjlj-exceptions. mingw-w64 is configured without --enable-sjlj-exceptions. But if we compile all code, including libraries, with one compiler, it should be safe. > On the other hand, MinGW-w64 packages inside Ubuntu > is also not that usable since it is quite old (even for the > upcoming 11.10). So I always use other versions. But Debian > Sid seems to be better in this aspect. > I use Debian. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build error with mingw32
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 is probably because you have a very old version of MinGW > and MinGW Win32-API. Seems to be a problem with Debian. > http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/RuntimeLibrary/Win32-API/ > > Debian seems to ship a 3-year old MinGW Win32-API. > http://packages.debian.org/search?searchon=sourcenames&keywords=mingw32 > Hmm, good point. I have written an email to the mingw32-runtime package maintainer of Debian to see if he has any plan to update it to the latest version. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Build error with mingw32
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: >>> >>>> 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 -Werror -o openocd.exe main.o >>>> -L/home/jie/installs/openocd/lib ./.libs/libopenocd.a -lws2_32 >>>> ../jimtcl/libjim.a >>>> ./.libs/libopenocd.a(libhelper_la-command.o): In function >>>> `process_jim_events': >>>> /home/jie/sources/openocd/src/helper/command.c:1398: undefined >>>> reference to `_Jim_ProcessEvents' >>>> collect2: ld returned 1 exit status >>>> make[4]: *** [openocd.exe] Error 1 >>>> make[4]: Leaving directory `/home/jie/sources/openocd/src' >>>> >>>> Jim_ProcessEvents is defined in jimtcl/jim-eventloop.c. >>>> >>>> set needs(eventloop) {expr {[have-feature select] || [have-feature >>>> usleep]}} >>>> >>>> but >>>> >>>> Checking for select...not found >>>> Checking for usleep...not found >>> >>> Can you send me jimtcl/config.log >>> >> Attached. >> >>> This is on Linux, right? >>> >> Yes. Debian testing AMD64. > > So, no usleep. Could it be a macro? I don't know. > Can you comment out that "needs(eventloop)" line and see if it works? Now I have no machine to test it. > Otherwise we will need to implement usleep() in terms of Sleep(). > Another option is to drop mingw32 and require mingw-w64. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build error with mingw32
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_MINGW_ANSI_STDIO -Wall >> -Wstrict-prototypes -Wformat-security -Wshadow -Wextra >> -Wno-unused-parameter -Wbad-function-cast -Wcast-align >> -Wredundant-decls -Werror -o openocd.exe main.o >> -L/home/jie/installs/openocd/lib ./.libs/libopenocd.a -lws2_32 >> ../jimtcl/libjim.a >> ./.libs/libopenocd.a(libhelper_la-command.o): In function >> `process_jim_events': >> /home/jie/sources/openocd/src/helper/command.c:1398: undefined >> reference to `_Jim_ProcessEvents' >> collect2: ld returned 1 exit status >> make[4]: *** [openocd.exe] Error 1 >> make[4]: Leaving directory `/home/jie/sources/openocd/src' >> >> Jim_ProcessEvents is defined in jimtcl/jim-eventloop.c. >> >> set needs(eventloop) {expr {[have-feature select] || [have-feature usleep]}} >> >> but >> >> Checking for select...not found >> Checking for usleep...not found > > Can you send me jimtcl/config.log > Attached. > This is on Linux, right? > Yes. Debian testing AMD64. Jie Invoked as: .././jimtcl/configure --with-jim-ext=nvp --disable-lineedit --disable-install-jim --disable-option-checking --prefix=/home/jie/installs/openocd --enable-maintainer-mode --host=i586-mingw32msvc host_alias=i586-mingw32msvc --cache-file=/dev/null --srcdir=. Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o conftest__.c:1:24: error: sys/socket.h: No such file or directory child process exited abnormally The failed code was: #include int main(void) { return 0; } Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o conftest__.c:1:24: error: netinet/in.h: No such file or directory child process exited abnormally The failed code was: #include int main(void) { return 0; } Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o conftest__.c:1:23: error: arpa/inet.h: No such file or directory child process exited abnormally The failed code was: #include int main(void) { return 0; } Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o conftest__.c:1:19: error: netdb.h: No such file or directory child process exited abnormally The failed code was: #include int main(void) { return 0; } Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o conftest__.c:1:20: error: sys/un.h: No such file or directory child process exited abnormally The failed code was: #include int main(void) { return 0; } Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o conftest__.c:1:19: error: dlfcn.h: No such file or directory child process exited abnormally The failed code was: #include int main(void) { return 0; } Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o conftest__.c:1:25: error: crt_externs.h: No such file or directory child process exited abnormally The failed code was: #include int main(void) { return 0; } Failed: ccache i586-mingw32msvc-cc -g -O2 conftest__.c -o conftest__.o /tmp/cca3kbgO.o: In function `main': /home/jie/sources/openocd/jimtcl/conftest__.c:3: undefined reference to `_ualarm' collect2: ld returned 1 exit status child process exited abnormally The failed code was: extern void ualarm(void); int main(void) { ualarm(); return 0; } Failed: ccache i586-mingw32msvc-cc -g -O2 conftest__.c -o conftest__.o /tmp/ccOSxm7T.o: In function `main': /home/jie/sources/openocd/jimtcl/conftest__.c:3: undefined reference to `_sysinfo' collect2: ld returned 1 exit status child process exited abnormally The failed code was: extern void sysinfo(void); int main(void) { sysinfo(); return 0; } Failed: ccache i586-mingw32msvc-cc -g -O2 conftest__.c -o conftest__.o /tmp/ccmzHPx4.o: In function `main': /home/jie/sources/openocd/jimtcl/conftest__.c:3: undefined reference to `_lstat' collect2: ld returned 1 exit status child process exited abnormally The failed code was: extern void lstat(void); int main(void) { lstat(); return 0; } Failed: ccache i586-mingw32msvc-cc -g -O2 conftest__.c -o conftest__.o conftest__.c:1: warning: conflicting types for built-in function 'fork' /tmp/cckd557b.o: In function `main': /home/jie/sources/openocd/jimtcl/conftest__.c:3: undefined reference to `_fork' collect2: ld returned 1 exit status child process exited abnormally The failed code was: extern void fork(
[Openocd-development] Build error with mingw32
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 -Werror -o openocd.exe main.o -L/home/jie/installs/openocd/lib ./.libs/libopenocd.a -lws2_32 ../jimtcl/libjim.a ./.libs/libopenocd.a(libhelper_la-command.o): In function `process_jim_events': /home/jie/sources/openocd/src/helper/command.c:1398: undefined reference to `_Jim_ProcessEvents' collect2: ld returned 1 exit status make[4]: *** [openocd.exe] Error 1 make[4]: Leaving directory `/home/jie/sources/openocd/src' Jim_ProcessEvents is defined in jimtcl/jim-eventloop.c. set needs(eventloop) {expr {[have-feature select] || [have-feature usleep]}} but Checking for select...not found Checking for usleep...not found It build OK with mingw-w64 since Checking for usleep...ok Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
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 need to handle this tricky situation. Like LOG_ERROR("FT_Write failed:%s\n", ftd2xx_status_string(status)); >>> >>> That sounds *way* better. And more helpful to the user, too. If it's >>> available in all recent ftd2xx versions on all platforms, I'd say it's a >>> go. >>> Any takers for putting together the patch? >>> /Andreas >>> >> >> Anyone having a go at this - if not i may get a chance later on in the >> week? >> >> Cheers >> Spen > > I have merged a patch that should sort all these warnings out. > Thanks. But it's on your git tree, not on the public one, right? Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
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 merge. So for bisect point of >> view it's not good > > An objection I have to patches is that they do not contain any information > about which commit they were tested against. > > git pull w/merge preserves that information. It is possible to make a > linear history > later on if required. > All patches should be tested on the latest upstream before merge, shouldn't it? If we follow this rule, we can keep the linear history and know the patch has been tested just on the HEAD before it's committed. The commit they were tested against when they were being developed is not so important then. The developer, who develops the patches, might still want to remember that commit to debug bugs in his patches found later, but others can always make sure those patches have been tested on the HEAD when they are committed. For example, one developer has a branch which was branched off from upstream one month ago and asks for merging the branch to the upstream. But during the past month, something might have changed in upstream, which would cause break after merging his branch into the upstream. Tested against a one-month old commit does not guarantee that it should work as expected after merge. The developer surely should rebase his branch to the current HEAD of master to resolve any issues and do a testing to make sure his branch works as correctly on the current HEAD before ask for a pull to merge. I would like a clean, atomic, linear history in the upstream. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Replace "script" with "source"
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-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Replace "script" with "source"
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/openocd-development/2011-July/020370.html >> >> If there is any issue, we still have enough time to revert this change. > > I don't see any advantage to removing 'script'. > I think it is better to have script evaluate in global scope. > Then could you make a patch and merge it. I have no strong opinion on this. Thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] remove useless pxref to SMP subsection
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 |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/doc/openocd.texi b/doc/openocd.texi index e3934e8..8b7e588 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -1677,7 +1677,7 @@ Again using the at91sam7 as an example, this can look like: $_TARGETNAME configure -work-area-phys 0x0020 \ -work-area-size 0x4000 -work-area-backup 0 @end example -@pxref{Define CPU targets working in SMP} + @anchor{Define CPU targets working in SMP} @subsection Define CPU targets working in SMP @cindex SMP -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] "Code review" and "git pull"
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 before >> he/she asks for pull, right? > > I think inline for review and a pull request once all issues have been > settled for patch series works well. > Good. I was a little worried that patch would be pulled without review. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] "Code review" and "git pull"
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.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
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=i686-pc-mingw32 >> --disable-shared --disable-werror --enable-ft2232_ftd2xx >> > > Yes --disable-werror is necessary. If not the following errors > will come out. I remember Jie Zheng has some proposals to > fix this. > > ../../../../src/jtag/drivers/ft2232.c: In function 'ft2232_write': > ../../../../src/jtag/drivers/ft2232.c:518:3: error: format '%u' > expects type 'unsigned int', but argument 6 has type 'FT_STATUS' Yes. And Spencer said he would fix it if he got a chance. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Replace "script" with "source"
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
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 resulted binary. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
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 >>> >>> LOG_ERROR("FT_Write failed:%s\n", >>> ftd2xx_status_string(status)); >>> >> >> That sounds *way* better. And more helpful to the user, too. If it's >> available in all recent ftd2xx versions on all platforms, I'd say it's a go. >> Any takers for putting together the patch? >> /Andreas >> > > Anyone having a go at this - if not i may get a chance later on in the week? > Please, thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Reset fails LM3S Tempest C5 due to failure to read device class
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: > > set device_class [expr (([mrw 0x400fe000] >> 16) & 0xff)] > > This memory location contains the device class. Tempest is 0x04. > > There is an errata where LM3S3N26 misreports itself as 0x03. > > My attempt at a workaround was to define a variable: > > set DEVICECLASSIS 0x04 > How did you define it? > then call a modified stellaris.cfg: > How did you call it? If you defined DEVICECLASSIS in a config file and used a "-f" option to add that config file and a "-f" to add stellaris.cfg, sellaris.cfg could not see DEVICECLASSIS because it was not a global variable. You will need to declare it as global explicitly. Weird? See the thread "script vs source" I started several days ago for an explanation. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Better fixes for set but not used warnings
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 set-but-not-used >>>> warnings are not correct or not good. This patch should be an >>>> improvement. Please review and merge if good. >>>> >>>> >>> >>> I am going to look into tis one, as one minute the code is there, next >>> minute it was deleted - very strange. >>> >> To ease your review, the related commits are >> >> f6315d5e5b7b71515ef051711e5f818a42d6b3b3 smp.c >> >> 1cfb2287a67c1f78b76583b2e5ed83ca3560b0d5 etb.c >> > > Cool you patch looks fine - i will commit. > Thank you! > Just for info this function was first broken in > d7f71e7fe9645fa8c3f88cf6fc9ad438aa6708f3. > The whitespace cleanup was a very strict indeed :) > It has been broken for more than 2 years but no one noticed it. It seems no one use that piece of code. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
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. >> >> - LOG_ERROR("FT_Write returned: %lu", status); >> + LOG_ERROR("FT_Write returned: %lu", (unsigned long)status); > > The type of status is ULONG, which is "unsigned long" on Windows but > is "unsigned int" on Linux in FTD2XX driver. So the problem is "%lu" > is not right for status on Linux. If we don't want cast, I think we > can do something like: > > #ifdef __WINDOWS_TYPES__ /* if FTD2XX WinTypes.h is included */ > #define PRulong "u" > #else > #define PRulong "lu" > #endif > > LOG_ERROR("FT_Write returned: %"PRulong, status); > 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 LOG_ERROR("FT_Write failed:%s\n", ftd2xx_status_string(status)); UrJTAG uses this method. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
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 will cause compile warnings when compiling for Windows host, I think. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Better fixes for set but not used warnings
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 good. >> >> > > I am going to look into tis one, as one minute the code is there, next > minute it was deleted - very strange. > To ease your review, the related commits are f6315d5e5b7b71515ef051711e5f818a42d6b3b3 smp.c 1cfb2287a67c1f78b76583b2e5ed83ca3560b0d5 etb.c Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
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 "script" command completely. > This is a newer version. Jie From cdf843cd871cbd42d54fe548d5c5cb146b5b4c12 Mon Sep 17 00:00:00 2001 From: Jie Zhang Date: Fri, 29 Jul 2011 11:17:54 -0400 Subject: [PATCH] remove "script" command --- src/ecosboard.c |2 +- src/helper/configuration.c|2 +- src/helper/options.c |2 +- src/helper/startup.tcl|7 --- tcl/interface/calao-usb-a9260-c01.cfg |4 ++-- tcl/interface/calao-usb-a9260-c02.cfg |4 ++-- 6 files changed, 7 insertions(+), 14 deletions(-) diff --git a/src/ecosboard.c b/src/ecosboard.c index 0805e6f..a522160 100644 --- a/src/ecosboard.c +++ b/src/ecosboard.c @@ -1123,7 +1123,7 @@ int main(int argc, char *argv[]) command_run_line(cmd_ctx, "debug_level 3"); } - command_run_linef(cmd_ctx, "script /rom/openocd.cfg"); + command_run_linef(cmd_ctx, "source [find /rom/openocd.cfg]"); int ret; ret = server_init(cmd_ctx); diff --git a/src/helper/configuration.c b/src/helper/configuration.c index eedd8a1..752b338 100644 --- a/src/helper/configuration.c +++ b/src/helper/configuration.c @@ -116,7 +116,7 @@ int parse_config_file(struct command_context *cmd_ctx) char **cfg; if (!config_file_names) { - command_run_line(cmd_ctx, "script openocd.cfg"); + command_run_line(cmd_ctx, "source [find openocd.cfg]"); return ERROR_OK; } diff --git a/src/helper/options.c b/src/helper/options.c index f8db2cd..0d77fde 100644 --- a/src/helper/options.c +++ b/src/helper/options.c @@ -150,7 +150,7 @@ int parse_cmdline_args(struct command_context *cmd_ctx, int argc, char *argv[]) break; case 'f': /* --file | -f */ { -snprintf(command_buffer, 128, "script {%s}", optarg); +snprintf(command_buffer, 128, "source [find %s]", optarg); add_config_command(command_buffer); break; } diff --git a/src/helper/startup.tcl b/src/helper/startup.tcl index 2e2982c..dc43801 100644 --- a/src/helper/startup.tcl +++ b/src/helper/startup.tcl @@ -53,12 +53,5 @@ proc find {filename} { add_usage_text find "" add_help_text find "print full path to file according to OpenOCD search rules" -# Run script -proc script {filename} { - source [find $filename] -} -add_help_text script "filename of OpenOCD script (tcl) to run" -add_usage_text script "" - # diff --git a/tcl/interface/calao-usb-a9260-c01.cfg b/tcl/interface/calao-usb-a9260-c01.cfg index c660671..a7ae26a 100644 --- a/tcl/interface/calao-usb-a9260-c01.cfg +++ b/tcl/interface/calao-usb-a9260-c01.cfg @@ -8,6 +8,6 @@ interface ft2232 ft2232_layout jtagkey ft2232_device_desc "USB-A9260" ft2232_vid_pid 0x0403 0x6010 -script interface/calao-usb-a9260.cfg -script target/at91sam9260minimal.cfg +source [find interface/calao-usb-a9260.cfg] +source [find target/at91sam9260minimal.cfg] diff --git a/tcl/interface/calao-usb-a9260-c02.cfg b/tcl/interface/calao-usb-a9260-c02.cfg index 2461b70..073c9a3 100644 --- a/tcl/interface/calao-usb-a9260-c02.cfg +++ b/tcl/interface/calao-usb-a9260-c02.cfg @@ -8,6 +8,6 @@ interface ft2232 ft2232_layout jtagkey ft2232_device_desc "USB-A9260" ft2232_vid_pid 0x0403 0x6001 -script interface/calao-usb-a9260.cfg -script target/at91sam9260minimal.cfg +source [find interface/calao-usb-a9260.cfg] +source [find target/at91sam9260minimal.cfg] -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
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 "script" command completely. Jie From f00a57d009fb713091b096521e82600a2e2401c2 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(-) diff --git a/src/helper/configuration.c b/src/helper/configuration.c index eedd8a1..752b338 100644 --- a/src/helper/configuration.c +++ b/src/helper/configuration.c @@ -116,7 +116,7 @@ int parse_config_file(struct command_context *cmd_ctx) char **cfg; if (!config_file_names) { - command_run_line(cmd_ctx, "script openocd.cfg"); + command_run_line(cmd_ctx, "source [find openocd.cfg]"); return ERROR_OK; } diff --git a/src/helper/options.c b/src/helper/options.c index f8db2cd..0d77fde 100644 --- a/src/helper/options.c +++ b/src/helper/options.c @@ -150,7 +150,7 @@ int parse_cmdline_args(struct command_context *cmd_ctx, int argc, char *argv[]) break; case 'f': /* --file | -f */ { -snprintf(command_buffer, 128, "script {%s}", optarg); +snprintf(command_buffer, 128, "source [find %s]", optarg); add_config_command(command_buffer); break; } diff --git a/src/helper/startup.tcl b/src/helper/startup.tcl index 2e2982c..dc43801 100644 --- a/src/helper/startup.tcl +++ b/src/helper/startup.tcl @@ -53,12 +53,5 @@ proc find {filename} { add_usage_text find "" add_help_text find "print full path to file according to OpenOCD search rules" -# Run script -proc script {filename} { - source [find $filename] -} -add_help_text script "filename of OpenOCD script (tcl) to run" -add_usage_text script "" - # -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Better fixes for set but not used warnings
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/target/etb.c @@ -304,20 +304,32 @@ static int etb_write_reg(struct reg *reg, uint32_t value) { struct etb_reg *etb_reg = reg->arch_info; uint8_t reg_addr = etb_reg->addr & 0x7f; + struct scan_field fields[3]; LOG_DEBUG("%i: 0x%8.8" PRIx32 "", (int)(etb_reg->addr), value); etb_scann(etb_reg->etb, 0x0); etb_set_instr(etb_reg->etb, 0xc); + fields[0].num_bits = 32; uint8_t temp0[4]; + fields[0].out_value = temp0; buf_set_u32(&temp0, 0, 32, value); + fields[0].in_value = NULL; + fields[1].num_bits = 7; uint8_t temp1; + fields[1].out_value = &temp1; buf_set_u32(&temp1, 0, 7, reg_addr); + fields[1].in_value = NULL; + fields[2].num_bits = 1; uint8_t temp2; + fields[2].out_value = &temp2; buf_set_u32(&temp2, 0, 1, 1); + fields[2].in_value = NULL; + + jtag_add_dr_scan(etb_reg->etb->tap, 3, fields, TAP_IDLE); return ERROR_OK; } diff --git a/src/target/smp.c b/src/target/smp.c index f4adc8d..ec157d3 100644 --- a/src/target/smp.c +++ b/src/target/smp.c @@ -79,7 +79,7 @@ int gdb_read_smp_packet(struct connection *connection, hex_buffer[2 * i + 1] = DIGITS[t & 0xf]; } - gdb_put_packet(connection, hex_buffer, len * 2); + retval = gdb_put_packet(connection, hex_buffer, len * 2); free(hex_buffer); } @@ -95,6 +95,7 @@ int gdb_write_smp_packet(struct connection *connection, { char *separator; int coreid = 0; + int retval = ERROR_OK; /* skip command character */ if (target->smp) @@ -104,13 +105,13 @@ int gdb_write_smp_packet(struct connection *connection, packet+=2; coreid = strtoul(packet, &separator, 16); target->gdb_service->core[1] = coreid; - gdb_put_packet(connection, "OK", 2); + retval = gdb_put_packet(connection, "OK", 2); } } else { - gdb_put_packet(connection,"E01",3); + retval = gdb_put_packet(connection,"E01",3); } - return ERROR_OK; + return retval; } ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
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 repository. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
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 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 define a global variable >> >> set foo 1 >> >> in target config file, then trying to read its value by >> >> obj = Jim_GetGlobalVariableStr (interp, "foo", 0); >> Jim_GetLong(interp, obj, &foo); >> > > use global, eg. > global foo > set foo 1 > This trick works, but not pretty. So I asked why we added "script" wrapper for "source" command Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
Let's me explain more on what I'm trying to do. In Blackfin gdbproxy, I hardcoded memory maps in C source code. When moving to OpenOCD, I'm trying to put them in the config files, which is something in my TODO list for a long time. At that time I thought about using an XML file for this purpose. But since OpenOCD has builtin tcl, I'm trying to save some time by just using tcl. So I can define set sdram_start 0 set sdram_end 0x2000 in the target config file and then target create function can read these variables to create a memory map. I'm still considering using XML, since tcl is good for memory maps but not good for MMRs when MMRs have different size. Do you think it's a good idea to linked in expat library? Jie 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"? > > On Jul 29, 2011 12:45 PM, "Jie Zhang" wrote: >> 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 define a global variable >> >> set foo 1 >> >> in target config file, then trying to read its value by >> >> obj = Jim_GetGlobalVariableStr (interp, "foo", 0); >> Jim_GetLong(interp, obj, &foo); >> >> in OpenOCD will fail because "foo" is not defined in global namespace. >> And the following code in a target config file will not work as >> expected: >> >> set foo 1 >> proc test { } { >> puts $::foo >> } >> test >> >> It's counterintuitive. >> >> Is this effect is by design or by accident? I can see that using >> "script" command can avoid name conflicts between config files. But it >> prevents config files from sharing global variables. It also prevents >> OpenOCD from accessing global variables defined in config files by >> Jim_GetGlobalVariableStr. >> >> Regards, >> Jie >> ___ >> Openocd-development mailing list >> Openocd-development@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] script vs source
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 define a global variable set foo 1 in target config file, then trying to read its value by obj = Jim_GetGlobalVariableStr (interp, "foo", 0); Jim_GetLong(interp, obj, &foo); in OpenOCD will fail because "foo" is not defined in global namespace. And the following code in a target config file will not work as expected: set foo 1 proc test { } { puts $::foo } test It's counterintuitive. Is this effect is by design or by accident? I can see that using "script" command can avoid name conflicts between config files. But it prevents config files from sharing global variables. It also prevents OpenOCD from accessing global variables defined in config files by Jim_GetGlobalVariableStr. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script command
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 openocd >>> source code, but could not find it. Thank you! >>> >>> Jie >> >> src/helper/startup.tcl line 57 > > And here's a trick for you. If you want to know > when any Tcl procedure is defined, you can run a command like: > > info source [info body script] > > This will show where the proc 'script' is defined. > Won't work for built-in commands, since there is no corresponding > source location. > Thank you! I have another question about script command. I will ask in a separate thread. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] script command
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-development
[Openocd-development] [PATCH] Remove deprecated '-p' option from doc
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 insertions(+), 2 deletions(-) diff --git a/doc/openocd.texi b/doc/openocd.texi index e9e32b8..7e99d5a 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -676,8 +676,6 @@ setting from within a telnet or gdb session using @command{debug_level You can redirect all output from the daemon to a file using the @option{-l } switch. -For details on the @option{-p} option. @xref{Connecting to GDB}. - Note! OpenOCD will launch the GDB & telnet server even if it can not establish a connection with the target. In general, it is possible for the JTAG controller to be unresponsive until the target is set up -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Update doc about Jim
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 |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/doc/openocd.texi b/doc/openocd.texi index fd92d51..e9e32b8 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -526,7 +526,7 @@ OpenOCD mailing list. @item @b{Jim vs. Tcl} @* Jim-Tcl is a stripped down version of the well known Tcl language, which can be found here: @url{http://www.tcl.tk}. Jim-Tcl has far -fewer features. Jim-Tcl is a single .C file and a single .H file and +fewer features. Jim-Tcl is several dozens of .C files and .H files and implements the basic Tcl command set. In contrast: Tcl 8.6 is a 4.2 MB .zip file containing 1540 files. -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to build openocd with debug symbols (-g)???
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-gnu, but your openocd is x86-64. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
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 >> >> It seems weird to have a configure option which causes 'make install' >> to not install. Seems like it will just confuse other users of jimtcl. >> > Maybe with a clear help documentation and a good default setting, it > will not be so confusing. I think we can have > --disable-install-jimtcl, default off, i.e, --enable-install-jimtcl, > for jimtcl. Then turn it on in OpenOCD. The help documentation could > be > > --disable-install-jimtcl controls installation of jimctl and related > headers. > usually used when jimctl is embeded in > another program. > > I'm also wondering if it's a good idea to make jimtcl use automake, > which should make implementing this easier. > Jim uses autosetup instead of autoconf. So it does not make much sense to use automake. Anyway I think Spencer's idea about adding a configure option to disable Jim installation is good. So I implemented it. I change the option name to "--disable-install-jim" to save 3 characters. Three patches are attached: jim-configure-disable-install.diff is for upstream Jim openocd-jim-configure-disable-install.diff is for Jim in OpenOCD openocd-dont-install-jimtcl.diff makes OpenOCD to use the new added configure option. Regards, Jie diff --git a/Makefile.in b/Makefile.in index 73c9cc8..0b031ae 100644 --- a/Makefile.in +++ b/Makefile.in @@ -7,6 +7,7 @@ STRIP = @STRIP@ # Configuration jim_libtype := @JIM_LIBTYPE@ +install_jim := @INSTALL_JIM@ SH_CFLAGS ?= @SH_CFLAGS@ SH_LDFLAGS ?= @SH_LDFLAGS@ SHOBJ_CFLAGS ?= @SHOBJ_CFLAGS@ @@ -60,6 +61,7 @@ $(JIMSH): $(LIBJIM) jimsh.o _initjimsh.o $(CC) $(CFLAGS) @SH_LINKFLAGS@ $(LDFLAGS) -o $@ jimsh.o _initjimsh.o $(LIBJIM) $(LDLIBS) install: all docs $(EXTENSION_TCL) install-exec +ifeq ($(install_jim),enable) mkdir -p $(DESTDIR)$(prefix)/lib/jim cp $(LIBJIM) $(DESTDIR)$(prefix)/lib cp @srcdir@/README.extensions $(C_EXT_SHOBJS) $(EXTENSION_TCL) $(DESTDIR)$(prefix)/lib/jim @@ -69,17 +71,22 @@ install: all docs $(EXTENSION_TCL) install-exec cp jim-config.h $(DESTDIR)$(prefix)/include mkdir -p $(DESTDIR)$(prefix)/doc/jim cp Tcl.html $(DESTDIR)$(prefix)/doc/jim +endif install-exec: all +ifeq ($(install_jim),enable) mkdir -p $(DESTDIR)$(prefix)/bin cp $(JIMSH) $(DESTDIR)$(prefix)/bin +endif uninstall: +ifeq ($(install_jim),enable) rm -f $(DESTDIR)$(prefix)/bin/$(JIMSH) rm -f $(DESTDIR)$(prefix)/lib/$(LIBJIM) for i in README.extensions $(C_EXT_SHOBJS) $(EXTENSION_TCL); do rm -f $(DESTDIR)$(prefix)/lib/jim/$$i; done rm -f $(DESTDIR)$(prefix)/include/jim*.h rm -f $(DESTDIR)$(prefix)/doc/jim/Tcl.html +endif test: $(JIMSH) $(DEF_LD_PATH) $(MAKE) jimsh=`pwd`/jimsh -C @srcdir@/tests diff --git a/auto.def b/auto.def index 0ac4dde..6540562 100644 --- a/auto.def +++ b/auto.def @@ -11,7 +11,8 @@ options { math=> "include support for math functions" ipv6=> "include ipv6 support in the aio extension" maintainer => {enable the [debug] command and JimPanic} -full=> "Enable some optional features: ipv6, math, utf8, binary, oo, tree" +full=> "enable some optional features: ipv6, math, utf8, binary, oo, tree" +install-jim=1 => "disable installation, useful when Jim is embedded in applications" with-jim-shared shared => "build a shared library instead of a static library" jim-regexp => "use the built-in (Tcl-compatible) regexp, even if POSIX regex is available" with-jim-ext: {with-ext:"ext1 ext2 ..."} => { @@ -145,6 +146,12 @@ if {[opt-bool references]} { msg-result "Enabling references" define JIM_REFERENCES } +if {[opt-bool install-jim]} { +define INSTALL_JIM "enable" +} else { +msg-result "Disabling installation" +define INSTALL_JIM "disable" +} if {[opt-bool shared with-jim-shared]} { msg-result "Building shared library" define JIM_LIBTYPE shared diff --git a/Makefile.in b/Makefile.in index 80ea37f..ac709db 100644 --- a/Makefile.in +++ b/Makefile.in @@ -7,6 +7,7 @@ STRIP = @STRIP@ # Configuration jim_libtype := @JIM_LIBTYPE@ +install_jim := @INSTALL_JIM@ SH_CFLAGS ?= @SH_CFLAGS@ SH_LDFLAGS ?= @SH_LDFLAGS@ SHOBJ_CFLAGS ?= @SHOBJ_CFLAGS@ @@ -56,6 +57,7 @@ $(JIMSH): $(LIBJIM) jimsh.o $(CC) $(CFLAGS) @SH_LINKFLAGS@ $(LDFLAGS) -o $@ jimsh.o $(LIBJIM) $(LDLIBS) install: all docs $(EXTENSION_TCL) install-exec +ifeq ($(install_jim),enable) mkdir -p $(DESTDIR)$
Re: [Openocd-development] Building local bootstrap jimsh0 failed
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 install. Seems like it will just confuse other users of jimtcl. > Maybe with a clear help documentation and a good default setting, it will not be so confusing. I think we can have --disable-install-jimtcl, default off, i.e, --enable-install-jimtcl, for jimtcl. Then turn it on in OpenOCD. The help documentation could be --disable-install-jimtcl controls installation of jimctl and related headers. usually used when jimctl is embeded in another program. I'm also wondering if it's a good idea to make jimtcl use automake, which should make implementing this easier. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
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 >>>> >>> >>> 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 jimtcl any more. >> > > I thought that to, but do s distclean and check again. > Simply using noinst_SUBDIRS means make never gets called in the jimtcl dir. > You are right. Automake does not support noinst_SUBDIRS. It has noinst_PROGRAMS, noinst_LIBRARIES, and noinst_HEADERS. But they need to be used in jimctl/ . Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
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 jimtcl any more. Regards, Jie diff --git a/Makefile.am b/Makefile.am index 1b19ba4..a02ed1b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -13,12 +13,10 @@ nobase_dist_pkgdata_DATA = \ contrib/openocd.udev if INTERNAL_JIMTCL -SUBDIRS = jimtcl -else -SUBDIRS = +noinst_SUBDIRS = jimtcl endif -SUBDIRS += src doc +SUBDIRS = src doc EXTRA_DIST = \ BUGS \ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] libswd drivers question
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, so it cannot be compiled in into libswd, but > rather linked with libswd during application compilation. However > libswd then complains about missing driver functions at linking time. > > For UrJTAG I have copied sources of libswd into application source > tree and passed proper source file with driver functions to compile > everything and then link with urjtag binary. This was fine until I > included LibSWD as OpenOCD submodule, because now it requires its own > empty drivers to compile, and those drivers override openocd's > drivers. When I removed template drivers from libswd source tree so it > can be linked with drivers already compiled and provided by openocd, > there are some unresolved dependencies in libswd.la submodule. This is > the only thing that keeps me from running libswd on openocd :-) > Do you have a step by step instruction to reproduce this issue? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bootstrap wrarning under Ubuntu 11.04
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$ ./bootstrap > + aclocal > configure.in:2: warning: AC_INIT: not a literal: OpenOCD Mailing List > It's a bug of autoconf. It has been fixed in autoconf-2.68. See http://savannah.gnu.org/support/?107450 Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] Defined but not used
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 function, means that the function is meant to be possibly unused. GCC will not produce a warning for this function. However, I don't think it's a good idea to leave unused function in source code. Such functions will soon rot and finally become useless and maintenance burden since it's not used anywhere. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC Release Cycle
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 you will pull & merge from us and push the result to the >>> master branch? >> exactly > > I'd have some reservations about only one person having write > access, but not particularly the way of working. Call me old fashioned. > It's not old fashioned. It's just how Linux works. Other projects have different release management processes. One kind of releasing process I know is (briefly): Multiple people have write access to the master branch. When the release manager think it's a good time to do a release, he/she will create a branch for that release. After that branch has been created, all new features will only go to the master branch. All fixes will go to the master branch as well as to the release branch if they are needed there. Developers can cherry-pick their fix from master to the release branch under approval of release manager, or the release manager can do the cherry-picking. When the release branch comes to a good status, the release manager roll out a release. Several very large projects use this kind of process. It works well. Btw, I don't think it's a good idea to put release branch in a separate git repository. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0-rc1 release
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/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
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: %lu", (unsigned long)status); The type of status is ULONG, which is "unsigned long" on Windows but is "unsigned int" on Linux in FTD2XX driver. So the problem is "%lu" is not right for status on Linux. If we don't want cast, I think we can do something like: #ifdef __WINDOWS_TYPES__ /* if FTD2XX WinTypes.h is included */ #define PRulong "u" #else #define PRulong "lu" #endif LOG_ERROR("FT_Write returned: %"PRulong, status); Just my $0.02. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] transport selection fix
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. > > Nice to know, thanks! Is that true for all compilers? > It's a C language extension provided by GCC. I don't think all compilers support this. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bugfix for adapter_khz_to_speed
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 actually outputting. > The latest git tree does not contains the code your patch tries to remove. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] partial support for dsp568013/568037
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 by the core) to see if it can send more data. if i > queue commands on jtag, how can i keep this working? won't all the > commands get shifted into jtag and eventually clog the system? If you need to check status often, you will need to flush JTAG often, that will slowdown the speed if you are using a USB JTAG cable. The method I use for Blackfin target I'm working on now is to add some waiting cycles instead of checking the status. The key is to find the minimal number of the required cycles. You will need experiments to find it out. I also used that method for UrJTAG/gdbproxy Blackfin target. It works very well. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unusual ARM chip
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 some sort of TAP controller, perhaps like an OMAP3. Has anyone > seen anything like this? Any idea how to get past it? > > Upon a scan, OpenOCD shows me: > > alex@msp-clx-aaustin:~$ openocd -f interface/jtagkey2.cfg -c jtag_khz\ 1 > Open On-Chip Debugger 0.5.0-dev-00219-g737c9b6-dirty (2010-05-06-14:21) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.berlios.de/doc/doxygen/bugs.html > 1 kHz > Info : max TCK change to: 3 kHz > Info : clock speed 1 kHz > Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!! > Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x30180083 > ..." > Warn : AUTO auto0.tap - use "... -irlen 8" > Warn : gdb services need one or more targets defined > I'm just starting working on OpenOCD and not familiar with it, so I don't know if it has a command with similar functionality, but the detect command in UrJTAG might give you more information about the TAPs in your target if you have not tried it yet. After you know the TAPs in your target, you can create a config file for your target for OpenOCD. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
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? > I didn't test it on the existing targets. But I think it should not do any harm to them. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Confusion about reset
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_process_reset_inner continues to assert SRST and then deassert SRST. But in startup.tcl, init_reset calls jim_jtag_arp_init_reset in tcl.c. (I'm not familiar with jim. I'm not sure if I'm right.) jim_jtag_arp_init_reset calls jtag_init_reset in core.c, which will also do SRST reset if RESET_HAS_SRST. So when RESET_HAS_SRST, SRST reset is done twice in one call to ocd_process_reset_inner. Is it redundant? From the comments in the source code, it's not necessary to do SRST reset in init_reset. Correct? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
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 usage. > > Your blackfin is fast enough. This "read usage" only affect you if you rape > the step command with > "some" register output to find a bug in your application/kernel/bootloader. > It's time to buy a > faster Jtag-Adapter. This is awesome! > We have very fast jtag adapters. But I want to squeeze as much as I can from the hardware. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
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 single register if it's supported by the gdb stub program. > But we should remember that some/all functions in the current implementation, > that need a target > register to work, simple doesn't check if a register already stored or not. > They only check if a > target is halted or not. > If target independent code doesn't check, I can help adding check to them. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
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 read usage. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Remove useless MIPS code in avr32_ap7k.c
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
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
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-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
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 regression test on my target. Thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Get register value if it's invalid in cache
Hi, Currently OpenOCD assumes that all targets read and save all registers in context when stop, and restore them when resume. But for the target I'm working on, the cost is too high to do that. My target has about 50 registers. Saving and restoring them needs much time. Usually GDB and users are only interested in several registers. So I don't want OpenOCD to save and restore all registers for my target. Instead, I hope OpenOCD reads/writes registers only when necessary. To achieve this, OpenOCD will invalidate all registers when target stops. If OpenOCD is asked for a register value but it's invalid, it will then read the register from the hardware and put them in the cache. When resume the target, OpenOCD will write all dirty cached registers back to hardware. handle_reg_command already checks if the register is valid in the cache and calls reg->type->get() to 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 2011 14:35:40 -0400 Subject: [PATCH] Get register value if it's invalid in cache. --- src/server/gdb_server.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/server/gdb_server.c b/src/server/gdb_server.c index 9c1d245..b29ee4f 100644 --- a/src/server/gdb_server.c +++ b/src/server/gdb_server.c @@ -1064,6 +1064,8 @@ static int gdb_get_registers_packet(struct connection *connection, for (i = 0; i < reg_list_size; i++) { + if (!reg_list[i]->valid) + reg_list[i]->type->get(reg_list[i]); gdb_str_to_target(target, reg_packet_p, reg_list[i]); reg_packet_p += DIV_ROUND_UP(reg_list[i]->size, 8) * 2; } @@ -1168,6 +1170,9 @@ static int gdb_get_register_packet(struct connection *connection, exit(-1); } + if (!reg_list[reg_num]->valid) + reg_list[reg_num]->type->get(reg_list[reg_num]); + reg_packet = malloc(DIV_ROUND_UP(reg_list[reg_num]->size, 8) * 2); gdb_str_to_target(target, reg_packet, reg_list[reg_num]); -- 1.7.2.5 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Remove useless MIPS code in avr32_ap7k.c
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 |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/src/target/avr32_ap7k.c b/src/target/avr32_ap7k.c index 70e5129..afac664 100644 --- a/src/target/avr32_ap7k.c +++ b/src/target/avr32_ap7k.c @@ -110,7 +110,6 @@ int avr32_ap7k_restore_context(struct target *target) static int avr32_read_core_reg(struct target *target, int num) { uint32_t reg_value; - struct avr32_core_reg *mips_core_reg; /* get pointers to arch-specific information */ struct avr32_ap7k_common *ap7k = target_to_ap7k(target); @@ -118,7 +117,6 @@ static int avr32_read_core_reg(struct target *target, int num) if ((num < 0) || (num >= AVR32NUMCOREREGS)) return ERROR_INVALID_ARGUMENTS; - mips_core_reg = ap7k->core_cache->reg_list[num].arch_info; reg_value = ap7k->core_regs[num]; buf_set_u32(ap7k->core_cache->reg_list[num].value, 0, 32, reg_value); ap7k->core_cache->reg_list[num].valid = 1; @@ -130,7 +128,6 @@ static int avr32_read_core_reg(struct target *target, int num) static int avr32_write_core_reg(struct target *target, int num) { uint32_t reg_value; - struct avr32_core_reg *mips_core_reg; /* get pointers to arch-specific information */ struct avr32_ap7k_common *ap7k = target_to_ap7k(target); @@ -139,7 +136,6 @@ static int avr32_write_core_reg(struct target *target, int num) return ERROR_INVALID_ARGUMENTS; reg_value = buf_get_u32(ap7k->core_cache->reg_list[num].value, 0, 32); - mips_core_reg = ap7k->core_cache->reg_list[num].arch_info; ap7k->core_regs[num] = reg_value; LOG_DEBUG("write core reg %i value 0x%" PRIx32 "", num , reg_value); ap7k->core_cache->reg_list[num].valid = 1; -- 1.7.2.5 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Why not default halt the target when GDB connects to OpenOCD?
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 reaches a special code line. > I think you can still connect to the target to look at the call stack and PC after it crashes. When I want to look at the call stack and PC at a special code line, I usually set a breakpoint from GDB, that will requires to halt the target first. > It's not a good idea to force everyone to halt their target when > connecting, when there is the possibility to script this behavior. It > might be your case that you want to halt it, but some other may not want > that. > Yes, it won't be a good idea to force everyone to halt their target if they usually don't. But it will also not be a good idea if people manually halt their target in most cases. GDB expects the target to be stopped when it connects to the target. But OpenOCD has this feature for several years, I think there must be some reasons. I'm trying to understand them. > In your case I think it would be the best to write a "gdb-attach" event > in your script and you can do whatever you want, like resetting the CPU, > blink LED's in this script. > This is what I'm currently doing. But I'm not sure if it's the correct thing to do since most of the board config files have "reset init" for their gdb-attach event, not "halt", except u8500.cfg. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Read register using GDB
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 "monitor" commands, you can > easily manipulate the target, e.g. issuing a "monitor halt". > I would say that this is confusing for a new user, like me, since it's different to the normal usage model of GDB. For example, when GDB attaches to a user application, it's expected that the application will be stopped. What are the other advantages? If they are important, we can consider changing GDB not to expect target halted when it connects to OpenOCD. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Why not default halt the target when GDB connects to OpenOCD?
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Why not default halt the target when GDB connects to OpenOCD?
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 OpenOCD does not halt the target when GDB connects, it will return all zeros when GDB asks for register value. GDB cached such value internally. Then I typed "monitor halt" in GDB, OpenOCD halts the target. But when I ask GDB about the register value of the target, GDB still returns the cached all zeros to me without retrieving them again. This bacause GDB has no idea that the target is still running when it connects to OpenOCD and the target is halted by "monitor halt". To get meaningful register values, I have to "continue" and "^C" in GDB to cause GDB to retrieve register values again. Then my question is why not just halt the target when GDB connects to OpenOCD? In this way, GDB will get the correct register information when it connects to OpenOCD and show the correct stop address. Regards Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Read register using GDB
This solves my problem. Thank you! I have another related issue, but I will start a new thread. Jie On Mon, May 2, 2011 at 12:33 PM, Mathias K. wrote: > If you stop the target you should store the target context into the local > register cache and if you > resume the target you 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 in > OpenOCD have this issue. > > Maybe I missed something... > > > > Jie > > > > On Mon, May 2, 2011 at 12:13 PM, Mathias K. kes...@freenet.de>> wrote: > > > > Hello, > > > > please tell us more about your target platform. > > > > > > 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. I > took a look at the related code > > > and found that when GDB requests register values from OpenOCD, > OpenOCD does not read register from > > > target, instead it just calls target_get_gdb_reg_list to create a > register list without > > initializing > > > it with real register value, and then just returns them to GDB. Is > it a bug or by design? > > > > > > Regards, > > > Jie > > > > > > > > > > > > ___ > > > Openocd-development mailing list > > > Openocd-development@lists.berlios.de Openocd-development@lists.berlios.de> > > > https://lists.berlios.de/mailman/listinfo/openocd-development > > > > > > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Read register using GDB
Thank you for your reply! I'm adding a new target to OpenOCD. But I think all existing targets in OpenOCD have this issue. Maybe I missed something... Jie On Mon, May 2, 2011 at 12:13 PM, Mathias K. wrote: > Hello, > > please tell us more about your target platform. > > > 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. I took a > look at the related code > > and found that when GDB requests register values from OpenOCD, OpenOCD > does not read register from > > target, instead it just calls target_get_gdb_reg_list to create a > register list without initializing > > it with real register value, and then just returns them to GDB. Is it a > bug or by design? > > > > Regards, > > Jie > > > > > > > > ___ > > Openocd-development mailing list > > Openocd-development@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/openocd-development > > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Read register using GDB
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 target, instead it just calls target_get_gdb_reg_list to create a register list without initializing it with real register value, and then just returns them to GDB. Is it a bug or by design? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development