[Openocd-development] New patch to review for openocd: afd5a73 * Add flash waitstate support for Atmel SAM3 chips. * Set default waitstates to 6, to workaround a silicon bug in the SAM3 family
This is an automated email from Gerrit.
Attila Kinali (att...@kinali.ch) just uploaded a new patch set to Gerrit, which
you can find at http://openocd.zylin.com/128
-- gerrit
commit afd5a73681eec417ded58a22fbe12336acdb0563
Author: Attila Kinali att...@kinali.ch
Date: Thu Oct 27 12:14:55 2011 +0200
* Add flash waitstate support for Atmel SAM3 chips.
* Set default waitstates to 6, to workaround a silicon bug in the SAM3
family
This code has been tested on SAM3U4, SAM3N4 and SAM3N1
based on Change-Id: I477446f9bfb3e910ea3e2414a6e9a75beb14a214
by Jim Norris u17...@att.net
Change-Id: I8d360080f6968979ca5e197ad638282cadd18fb7
Signed-off-by: Attila Kinali att...@kinali.ch
diff --git a/src/flash/nor/at91sam3.c b/src/flash/nor/at91sam3.c
index c46829e..b5442e8 100644
--- a/src/flash/nor/at91sam3.c
+++ b/src/flash/nor/at91sam3.c
@@ -183,6 +183,7 @@ struct sam3_bank_private {
unsigned bank_number;
uint32_t controller_address;
uint32_t base_address;
+ uint32_t flash_wait_states;
bool present;
unsigned size_bytes;
unsigned nsectors;
@@ -298,6 +299,7 @@ static const struct sam3_chip_details all_sam3_details[] = {
.bank_number = 0,
.base_address = FLASH_BANK0_BASE_U,
.controller_address = 0x400e0800,
+ .flash_wait_states = 6, // workaround silicon bug
.present = 1,
.size_bytes = 128 * 1024,
.nsectors = 16,
@@ -313,6 +315,7 @@ static const struct sam3_chip_details all_sam3_details[] = {
.bank_number = 1,
.base_address = FLASH_BANK1_BASE_U,
.controller_address = 0x400e0a00,
+ .flash_wait_states = 6, // workaround silicon bug
.present = 1,
.size_bytes = 128 * 1024,
.nsectors = 16,
@@ -347,6 +350,7 @@ static const struct sam3_chip_details all_sam3_details[] = {
.bank_number = 0,
.base_address = FLASH_BANK0_BASE_U,
.controller_address = 0x400e0800,
+ .flash_wait_states = 6, // workaround silicon bug
.present = 1,
.size_bytes = 128 * 1024,
.nsectors = 16,
@@ -388,6 +392,7 @@ static const struct sam3_chip_details all_sam3_details[] = {
.bank_number = 0,
.base_address = FLASH_BANK0_BASE_U,
.controller_address = 0x400e0800,
+ .flash_wait_states = 6, // workaround silicon bug
.present = 1,
.size_bytes = 64 * 1024,
.nsectors = 8,
@@ -436,6 +441,7 @@ static const struct sam3_chip_details all_sam3_details[] = {
.bank_number = 0,
.base_address = FLASH_BANK0_BASE_U,
.controller_address = 0x400e0800,
+ .flash_wait_states = 6, // workaround silicon bug
.present = 1,
.size_bytes = 128 * 1024,
.nsectors = 16,
@@ -450,6 +456,7 @@ static const struct sam3_chip_details all_sam3_details[] = {
.bank_number = 1,
.base_address = FLASH_BANK1_BASE_U,
.controller_address = 0x400e0a00,
+ .flash_wait_states = 6, // workaround silicon bug
.present = 1,
.size_bytes = 128 * 1024,
.nsectors = 16,
@@ -484,6 +491,7 @@ static const struct sam3_chip_details all_sam3_details[] = {
.bank_number = 0,
.base_address = FLASH_BANK0_BASE_U,
.controller_address = 0x400e0800,
+ .flash_wait_states = 6, // workaround silicon bug
.present = 1,
.size_bytes = 128 * 1024,
.nsectors = 16,
@@ -525,6 +533,7 @@ static const struct sam3_chip_details all_sam3_details[] = {
.bank_number = 0,
.base_address = FLASH_BANK0_BASE_U,
.controller_address = 0x400e0800,
+ .flash_wait_states = 6, // workaround silicon bug
.present = 1,
.size_bytes = 64 * 1024,
.nsectors = 8,
@@ -561,8 +570,8 @@ static const struct sam3_chip_details all_sam3_details[] = {
.pBank = NULL,
.bank_number = 0,
.base_address = FLASH_BANK_BASE_S,
-
.controller_address = 0x400e0a00,
+
Re: [Openocd-development] git gui
On 26/10/2011 01:52, jim norris wrote: For those using a git gui, what are you using? 'gitg' on Linux. Having a GUI for hunk selection and commit is by far fastest then jumping trough various shells when writing a meaningful changelog message for the changes you are committing. Otherwise, I'm fine with the command line. -- Luca Ottaviano - lottavi...@develer.com Develer S.r.l. - http://www.develer.com/ .hardware .software .innovation Tel.: +39 055 3986627 - ext.: 218 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
Apologies to anyone for annoying this list again with what are mostly discussions about the libusb dysfunctionality. If you aren't interested in finding why projects become dysfunctional, and why people will take palliative action then, please ignore. On 2011.10.27 00:53, Peter Stuge wrote: It's not a good idea to use git as one sees fit if that ends up being unfit for others, Last time I checked, libusb-1.0 asked for patches to be submitted to the mailing list, thus I really fail to get why you should pay any attention to what goes on in -pbatard. Moreover I did create a specific integration branch some time ago off -pbatard, so that you could pick stuff directly from git if you wanted (more about this below). I have yet to hear anyone else but you complain about -pbatard, or find they couldn't work with it. If anyone really has anything to say about how atrocious it really is, please feel free to browse [1] and comment. If you want to pretend that my branch is unfit for others, then pray provide concrete examples of others complaining that it is unfit. and it's of course not a good idea to use anything in an inefficient way. As I explained, the way I use git is, after careful comparison, the way *I* found most efficient. If you believe there can only be one master way to be efficient for software development, I am starting to understand why libusb turned out so dysfunctional. I think it's difficult to find a setting where git doesn't offer some significant advantages over other common choices. You're misreading the point (as you've done over and over again when we debated this in libusb-devel). So, once again, this is not a statement about git vs X. This is a statement about git alone. Git does have limitations and areas where I personally find it is far from being intuitive. When I say that, I'm not comparing it with SVN or whatever. For the record, I like git a lot better than subversion, which I also use on regular basis. But I do find that a many aspects of git are unintuitive and could be improved on, even without looking at competitors. For instance, I explained how grid coordinates to designate commits to human users (while keeping hashes internally) would have been a better choice than simply reusing hashes, as it would offer an immediate way to also provide their chronological order when referenced. You can also read (and comment) on Indiana Git and the Intuitiveness of Doom [2], which is about setting a git remote repository or other annoyances like fast forward denying [3] (which, apparently means that some people believe that deleting public commits is a bad idea) to get an idea of my annoyances with git if you want more. Also don't try impose your views on others with regards to git usage, unless you really have something to say about the quality of the patches they submit to mainline. To clarify for those not following libusb, and to take a concrete example: Pete's public libusb repo isn't rebased on the main libusb repo merge queue, but is rather a fork of the main repo from when Pete started working on libusb. More or less (see below). That's because I couldn't possibly fathom that I'd have to keep maintaining that development branch for 2 years. I foolishly believed that libusb would start integrate my work quickly and wouldn't be as totally adverse to Release Early Release Often as it is (or, more exactly, as Peter is). Once they early patches were integrated, I could just produce the subsequent ones off mainline by rebasing, ensuring that I wouldn't have to waste too much time maintaining my own branch, and concentrate on development. My plan was always to wait for my patches to be integrated, drop -pbatard, as it WAS a personal development branch, and subsequently work off mainline. Yet, 2 years on and I'm still waiting for a single libusb release that integrates ANY of the Windows backend patches. If you want to kick somebody for Windows git development and integration not happening the way you'd like them to happen, you should really have a long hard look at yourself for doing everything you can to delay integration and release, and actually prevent people from using git the way it should be used. When a branch has to exist on its own, without any ties to mainline, because mainline keeps ignoring it for years, it does becomes a headache to use git as one should, because what you really end up with are 2 very independent branches. The only other alternative to not wasting my time would have been to stop all development until libusb caught up (which is pretty much what I am doing right now). Also, what you seem to miss, is that I do follow up with mainline by merging the changes that occur there, except I'm not using rebase, but I merge them in one big commit, since they don't matter for Windows development. So it's not a fork from when. It's just a fork. So, what really happens in -pbatard is that
Re: [Openocd-development] status of cortex-m0
On Thu, 27 Oct 2011 08:45:57 -0500, Christopher Harvey wrote: Xiaofan Chen, aren't you a versaloon developer? Your name is on the versaloon paypal order page. My bad. The Versaloon guy is Qian Xiaochen, not Xiaofan Chen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] status of cortex-m0
On Thu, 27 Oct 2011 13:08:57 +0800, Xiaofan Chen wrote: On Thu, Oct 27, 2011 at 11:24 AM, Christopher Harvey ch...@basementcode.com wrote: I read a thread about somebody who apparently got cortex m0 cores working with OpenOCD. (based on the m3 code). Did that patch ever get posted somewhere? Anybody following/working on m0 right now? The Cortex M0 support will most likely depend on the SWD support which is now on progress. Reference thread. http://lists.berlios.de/pipermail/openocd-development/2011-June/019303.html Not so sure about the status on Versaloon's swd implementation. You can check with Simon Qian. http://www.versaloon.com/index.html http://lists.berlios.de/pipermail/openocd-development/2011-April/018838.html thanks for the threads. I just ordered a Versaloon Mini. I saw there are swd related files in OpenOCD version 0.5.0, so I assumed it was supported. Also the versaloon site says: I can provide the patch for OpenOCD adding SWD support. OpenOCD will integrate SWD support in 0.5.0 release. Xiaofan Chen, aren't you a versaloon developer? Your name is on the versaloon paypal order page. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
On 10/27/2011 06:43 AM, Luca Ottaviano wrote: Having a GUI for hunk selection and commit is by far fastest then jumping trough various shells when writing a meaningful changelog message for the changes you are committing. +1. I use magit from within emacs for this (among other things). The *magit-status* buffer has a nice diff display. With point in a hunk, 's' stages the hunk; if there's a region, 's' stages the region (useful for e.g. staging a single changed line). I'm aware of git add -p; I find this faster. http://www.emacswiki.org/emacs/Magit ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: c5e0a7c clang: fix warning about missing check for return value
This is an automated email from Gerrit. ?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/129 -- gerrit commit c5e0a7c0a539e0fcacd2fd1333dda5adfb5e60cf Author: Øyvind Harboe oyvind.har...@zylin.com Date: Thu Oct 27 19:27:04 2011 +0200 clang: fix warning about missing check for return value Change-Id: I0c6b6b8d1f0c30b6a503cb98df30584252bc0ee1 Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com diff --git a/src/rtos/FreeRTOS.c b/src/rtos/FreeRTOS.c index 10a9b8c..eeab134 100644 --- a/src/rtos/FreeRTOS.c +++ b/src/rtos/FreeRTOS.c @@ -231,7 +231,8 @@ static int FreeRTOS_update_threads( struct rtos *rtos ) // Find out how many lists are needed to be read from pxReadyTasksLists, int64_t max_used_priority = 0; retval = target_read_buffer( rtos-target, rtos-symbols[FreeRTOS_VAL_uxTopUsedPriority].address, param-pointer_width, (uint8_t *)max_used_priority ); - + if (retval != ERROR_OK) + return retval; symbol_address_t* list_of_lists = (symbol_address_t *)malloc( sizeof( symbol_address_t ) * ( max_used_priority+1 + 5 ) ); -- ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] clang warnings
Hi, Spencer has gotten clang up and running again on the server! :-) Please take a moment to fix a warning or two that you can find in the latest warning list for clang builds. You'll notice that there is a nice graph that we can use to track our progress in terms of warnings. When reviewing, I'd like us not to increase # of warnings with new patches, but that check is not enforced yet via Gerrit verification flag. http://openocd.zylin.com/jenkins/job/openocd-clang/2/warningsResult/ -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clang warnings
On 27/10/2011 18:30, Øyvind Harboe wrote: Hi, Spencer has gotten clang up and running again on the server! :-) Please take a moment to fix a warning or two that you can find in the latest warning list for clang builds. You'll notice that there is a nice graph that we can use to track our progress in terms of warnings. When reviewing, I'd like us not to increase # of warnings with new patches, but that check is not enforced yet via Gerrit verification flag. http://openocd.zylin.com/jenkins/job/openocd-clang/2/warningsResult/ use this url and it will always take you to the latest warnings: http://openocd.zylin.com/jenkins/job/openocd-clang/lastBuild/warningsResult/? just for info we can also see the scan-build output if you prefer: http://openocd.zylin.com/jenkins/job/openocd-clang/ws/scan-build/index.html Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: e043913 bugfixes: numerous bugs in error propagation found by clang
This is an automated email from Gerrit.
?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/130
-- gerrit
commit e0439139e9f1cc6d811c6f9bce49a2e36f01163e
Author: Øyvind Harboe oyvind.har...@zylin.com
Date: Thu Oct 27 23:51:50 2011 +0200
bugfixes: numerous bugs in error propagation found by clang
Change-Id: I784068325b422d1918e28c08544bc5a1332d712f
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
diff --git a/src/target/target.c b/src/target/target.c
index d4cb577..bd15620 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -1863,11 +1863,9 @@ int target_write_u8(struct target *target, uint32_t
address, uint8_t value)
COMMAND_HANDLER(handle_targets_command)
{
- struct target *target = all_targets;
-
if (CMD_ARGC == 1)
{
- target = get_target(CMD_ARGV[0]);
+ struct target *target = get_target(CMD_ARGV[0]);
if (target == NULL) {
command_print(CMD_CTX,Target: %s is unknown, try one
of:\n, CMD_ARGV[0]);
goto DumpTargets;
@@ -1882,9 +1880,9 @@ COMMAND_HANDLER(handle_targets_command)
CMD_CTX-current_target = target-target_number;
return ERROR_OK;
}
-DumpTargets:
+DumpTargets:;
- target = all_targets;
+ struct target *target = all_targets;
command_print(CMD_CTX, TargetName Type Endian
TapNameState );
command_print(CMD_CTX, -- -- -- --
-- );
while (target)
@@ -2190,6 +2188,8 @@ COMMAND_HANDLER(handle_reg_command)
}
}
+ assert(reg != NULL); /* give clang a hint that we *know* reg is != NULL
here */
+
/* display a register */
if ((CMD_ARGC == 1) || ((CMD_ARGC == 2) !((CMD_ARGV[1][0] = '0')
(CMD_ARGV[1][0] = '9'
{
@@ -2210,6 +2210,8 @@ COMMAND_HANDLER(handle_reg_command)
if (CMD_ARGC == 2)
{
uint8_t *buf = malloc(DIV_ROUND_UP(reg-size, 8));
+ if (buf == NULL)
+ return ERROR_FAIL;
str_to_buf(CMD_ARGV[1], strlen(CMD_ARGV[1]), buf, reg-size, 0);
reg-type-set(reg, buf);
@@ -3414,9 +3416,9 @@ COMMAND_HANDLER(handle_profile_command)
/* hopefully it is safe to cache! We want to stop/restart as quickly as
possible. */
struct reg *reg = register_get_by_name(target-reg_cache, pc, 1);
+ int retval = ERROR_OK;
for (;;)
{
- int retval;
target_poll(target);
if (target-state == TARGET_HALTED)
{
@@ -3469,7 +3471,7 @@ COMMAND_HANDLER(handle_profile_command)
}
free(samples);
- return ERROR_OK;
+ return retval;
}
static int new_int_array_element(Jim_Interp * interp, const char *varname, int
idx, uint32_t val)
@@ -3634,7 +3636,7 @@ static int target_mem2array(Jim_Interp *interp, struct
target *target, int argc,
Jim_SetResult(interp, Jim_NewEmptyStringObj(interp));
Jim_AppendStrings(interp, Jim_GetResult(interp),
mem2array: cannot read memory, NULL);
e = JIM_ERR;
- len = 0;
+ break;
} else {
v = 0; /* shut up gcc */
for (i = 0 ;i count ;i++, n++) {
@@ -3659,7 +3661,7 @@ static int target_mem2array(Jim_Interp *interp, struct
target *target, int argc,
Jim_SetResult(interp, Jim_NewEmptyStringObj(interp));
- return JIM_OK;
+ return e;
}
static int get_int_array_element(Jim_Interp * interp, const char *varname, int
idx, uint32_t *val)
@@ -3844,7 +3846,7 @@ static int target_array2mem(Jim_Interp *interp, struct
target *target,
Jim_SetResult(interp, Jim_NewEmptyStringObj(interp));
Jim_AppendStrings(interp, Jim_GetResult(interp),
array2mem: cannot read memory, NULL);
e = JIM_ERR;
- len = 0;
+ break;
}
}
@@ -3852,7 +3854,7 @@ static int target_array2mem(Jim_Interp *interp, struct
target *target,
Jim_SetResult(interp, Jim_NewEmptyStringObj(interp));
- return JIM_OK;
+ return e;
}
/* FIX? should we propagate errors here rather than printing them
@@ -4164,6 +4166,8 @@ static int target_configure(Jim_GetOptInfo *goi, struct
target *target)
free((void *)(target-variant));
}
e = Jim_GetOpt_String(goi, cp, NULL);
+ if (e != JIM_OK)
+ return e;
target-variant = strdup(cp);
Re: [Openocd-development] New patch to review for openocd: e043913 bugfixes: numerous bugs in error propagation found by clang
ger...@openocd.zylin.com wrote: -DumpTargets: +DumpTargets:; Hm? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New patch to review for openocd: e043913 bugfixes: numerous bugs in error propagation found by clang
2011/10/28 Peter Stuge pe...@stuge.se: ger...@openocd.zylin.com wrote: -DumpTargets: +DumpTargets:; Hm? Syntactically a declaration can't follow a label, so add an empty statement. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New patch to review for openocd: e043913 bugfixes: numerous bugs in error propagation found by clang
Øyvind Harboe wrote: 2011/10/28 Peter Stuge pe...@stuge.se: ger...@openocd.zylin.com wrote: -DumpTargets: +DumpTargets:; Hm? Syntactically a declaration can't follow a label, so add an empty statement. I don't like the change so much. It ends up declaring the exact same variable twice, and other odd noise, to silence a warning. Is there no better way? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New patch to review for openocd: e043913 bugfixes: numerous bugs in error propagation found by clang
On Fri, Oct 28, 2011 at 12:23 AM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: 2011/10/28 Peter Stuge pe...@stuge.se: ger...@openocd.zylin.com wrote: -DumpTargets: +DumpTargets:; Hm? Syntactically a declaration can't follow a label, so add an empty statement. I don't like the change so much. It ends up declaring the exact same variable twice, and other odd noise, to silence a warning. Is there no better way? Reusing the 'target' variable name here is bad. They are really two very distinct variable lifetimes. The scope of the variables are now reduced. The code is now more easily re-factored as multiple functions because the same variable isn't being reused over and over for difference purposes. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New patch to review for openocd: e043913 bugfixes: numerous bugs in error propagation found by clang
Øyvind Harboe wrote: I don't like the change so much. It ends up declaring the exact same variable twice, and other odd noise, to silence a warning. Is there no better way? Reusing the 'target' variable name here is bad. .. The code is now more easily re-factored as multiple functions Ok, can we please do that then, instead of working around static analysis? Also, I'm not sure the command handler should really return ERROR_OK if the target is unknown. (Not a new bug, but I think it's a bug just the same.) //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New patch to review for openocd: e043913 bugfixes: numerous bugs in error propagation found by clang
On Fri, Oct 28, 2011 at 12:59 AM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: I don't like the change so much. It ends up declaring the exact same variable twice, and other odd noise, to silence a warning. Is there no better way? Reusing the 'target' variable name here is bad. .. The code is now more easily re-factored as multiple functions Ok, can we please do that then, instead of working around static analysis? In this case, I disagree that it is working around static analysis. I'll see about having a peek at the code again for cleaning it up. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: 6d22305 bugfixes: tinker a bit with the targets command
This is an automated email from Gerrit.
?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/131
-- gerrit
commit 6d223053e3b290678414c021b9f9da1f669d8de0
Author: Øyvind Harboe oyvind.har...@zylin.com
Date: Thu Oct 27 23:51:50 2011 +0200
bugfixes: tinker a bit with the targets command
return error when target can not be found instead of ERROR_OK,
split fn.
Change-Id: Iba5232d3862a490d0995c3bfece23685bd6856e3
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
diff --git a/src/target/target.c b/src/target/target.c
index bd15620..d28a9ca 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -1861,26 +1861,37 @@ int target_write_u8(struct target *target, uint32_t
address, uint8_t value)
return retval;
}
+static int find_target(struct command_context *cmd_ctx, const char *name)
+{
+struct target *target = get_target(name);
+if (target == NULL) {
+ LOG_ERROR(Target: %s is unknown, try one of:\n, name);
+ return ERROR_FAIL;
+}
+if (!target-tap-enabled) {
+ LOG_USER(Target: TAP %s is disabled,
+can't be the current target\n,
+target-tap-dotted_name);
+ return ERROR_FAIL;
+}
+
+cmd_ctx-current_target = target-target_number;
+return ERROR_OK;
+}
+
+
COMMAND_HANDLER(handle_targets_command)
{
+ int retval = ERROR_OK;
if (CMD_ARGC == 1)
{
- struct target *target = get_target(CMD_ARGV[0]);
- if (target == NULL) {
- command_print(CMD_CTX,Target: %s is unknown, try one
of:\n, CMD_ARGV[0]);
- goto DumpTargets;
- }
- if (!target-tap-enabled) {
- command_print(CMD_CTX,Target: TAP %s is disabled,
- can't be the current target\n,
- target-tap-dotted_name);
- return ERROR_FAIL;
- }
-
- CMD_CTX-current_target = target-target_number;
- return ERROR_OK;
+ retval = find_target(CMD_CTX, CMD_ARGV[0]);
+ if (retval == ERROR_OK)
+ {
+ /* we're done! */
+ return retval;
+ }
}
-DumpTargets:;
struct target *target = all_targets;
command_print(CMD_CTX, TargetName Type Endian
TapNameState );
@@ -1911,7 +1922,7 @@ DumpTargets:;
target = target-next;
}
- return ERROR_OK;
+ return ERROR_FAIL;
}
/* every 300ms we check for reset powerdropout and issue a reset halt if
so. */
--
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
