[Openocd-development] endstate command
How about retiring the endstate command? This command can't work unless polling is turned off as the global endstate gets overwritten by the background polling. If other commands such as drscan does not have a clearly defined default end-state then the endstate of such commands is effectively a random end state(since background polling will be enabled). -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Do not try to examine targets with disabled taps
On Saturday 06 June 2009, Rick Altherr wrote: Again, we don't have such cases today. We can speculate all kinds of things, but in the absence of real hardware I don't think the results of speculation are compelling. Plus, $target_name curstate has a very limited range of state outputs, and it would need to grow to accomodate such states. Actually, many Cortex-A8 designs include power/clock gating for the processor core. And some earlier ARMs do strange things in idle states too. ISTR that wait for interrupt (WFI) instructions may need special treatment with emulators in use; haven't had much need to look at it myself, before now. Such devices may have the TAP enabled, but the target isn't enabled because the power/clock is turned off to it. I'm not sure that a $target_name curstate is the right idea either since as you pointed out, it would need to grow to handle these cases and we won't necessarily know what all of them are. I think those are somewhat orthogonal issues though. Power gating is through a separate control framework, which one hopes is accessible without the CPU ... that seems to have been an 1149.7 goal (class T1 has power states), also something of a Nexus goal (in the sense that there seem to be bus access primitives that don't go through the CPU, I recall it as a separate TAP). Clock gating for ARM cores is coupled to stuff like the WFI instruction, but once the core is in a real debug mode at least some of them use that trick of having TCK drive the pipeline at debug speed. At any rate ... we agree that curstate is a trifle weak as models go. The IEEE 1149.7 stuff seems to incorporate a tap state model of sorts ... parts relevant to OpenOCD would be the power states, and whether it's routed into the scan chain or not. I'd say those use cases are relatively near future. Not so with target state. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232H based dongle with adaptive clocking support
Patrick Wieland wrote: The ftdi-2232-H monitors the RTCK signal on GPIOL4 If you find this pin, its okay. On design I use GPIOL3 ;) The PCB of the OOCDLink with RTCK support is laying in front of me, but I ran out of FT2232Hs to assemble it, so I have to wait until I get the ic from the distributors. Joern ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Do not try to examine targets with disabled taps
duane $TARGETNAME mdw
david Though mdw is really impractical for scripting.
yea, it's probably a very bad example, one probably needs to use
'$targetname mem2array or $targetname array2mem, or we can create a
helper sub-command
david A third option: too painful to use. How exactly is $_TARGETNAME
david going to get *into* the event handler since nothing binds the right
david value to that name??
david I'll tell you how. By hard-wiring a particular target name.
I presume you mean the $_TARGETNAME will not be valid when the event is
invoked. TK handles events with things like %w for the window path,
treating the event handler body sort of like an sprintf() format
string. Sadly, JIM is not that complicated, I thought about adding a %T
for the current target name. That would be a good future enhancement.
But - today I think what you mean is this:
Today, all target reset handlers are done like this:
$_targetname configure -event reset-init { CURLYBRACE }
TCL variable parsing rules mean that things in { CURLYBRACE } are not
not expanded right now.
The *could* be done like this:
$_targetname configure -event reset-init double-quoted-string
In the double-quoted case, the double-quoted method would cause the
embeded $_TARGETNAME to be expanded prior to invoking the configure
sub command.
david Some of that's a general event handler issue: the event handlers
have no invocation-specific context.
There is no doubt in my mind there are giant dragons we do not know about.
david [snip] But reset haltmeans I get a bare CPU, in need of
serious re-init, and using a slow JTAG clock...)
Good example of that is a complex multi-target board. However, that
senario presents an N-way way combination that we cannot today make
reusable code for. We can, however document each thing seperately - so
that the user/victim can figure out how to weave the two reset processes
they need together.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Do not try to examine targets with disabled taps
On Sunday 07 June 2009, Duane Ellis wrote:
But - today I think what you mean is this:
Today, all target reset handlers are done like this:
$_targetname configure -event reset-init { CURLYBRACE }
They aren't all like that, though. So the solution you list
below can't always work ... though the seeds of a workaround
are found there.
TCL variable parsing rules mean that things in { CURLYBRACE } are not
not expanded right now.
The *could* be done like this:
$_targetname configure -event reset-init double-quoted-string
In the double-quoted case, the double-quoted method would cause the
embeded $_TARGETNAME to be expanded prior to invoking the configure
sub command.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] endstate command
On Sunday 07 June 2009, Øyvind Harboe wrote: How about retiring the endstate command? No current in-tree users, FWIW. Make sure you remove the openocd.texi references to it too ... might want to first merge the openocd.texi user's guide tweaks patch I sent last week, so you don't break its patch context (i.e. so it can still apply). This command can't work unless polling is turned off as the global endstate gets overwritten by the background polling. If other commands such as drscan does not have a clearly defined default end-state Right now the drscan and irscan states *do* have such a clearly defined state. But using those commands with background activity would seem unwise. then the endstate of such commands is effectively a random end state(since background polling will be enabled). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Target AJAX like support - User Interface Thread
duane [ajax] david Saying AJAX or talking about any other implementation tech feels to me like putting the cart before the horse. Correct, I should have given more examples. What I ment was - 2 parts: 1) the GUI interface (a) could be built-in webserver + javascript (ajax) OR (b) could be built-in webserver + flash OR (c) could be Ecplipse + JAVA OR (d) could be Tcl/Tk app Perhaps the use of ajax is/was very premature - I really mean that sort of concept, nothing more. 2) The backend part the above pieces talk to. It responds to commands. = So what should we focus on? (A) Wizard type features to help *new*users* get started ie: Some build a basic configuration file tool. That could be *text* - ie: Answer questions, choose from a list. That's not 'inside openocd' - its more of a text configuration file' Could be as simple as Perl CPAN - text mode Or as simple as Linux Kernel make config text mode. (vrs make xconfig, or make menuconfig). (B) Day to day operational features. I think your view is more (A), and mine is more (B). -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] endstate command
On Sunday 07 June 2009, David Brownell wrote: How about retiring the endstate command? No current in-tree users, FWIW. ... except beagleboard init, sorry. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Target AJAX like support - User Interface Thread
On Sunday 07 June 2009, Duane Ellis wrote: So what should we focus on? (A) Wizard type features to help *new*users* get started (B) Day to day operational features. I think your view is more (A), and mine is more (B). Yet my example of a flash download tool seems more like (B) to me. :) Keep in mind also that while some day to day users are using GDB-over-JTAG to develop microcontroller software, others have more limited and infrequent demands, like de-bricking or (similar) installing new boot loaders. And I'd say that the former will be getting deeply familiar with command line tools, of necessity ... the latter are the ones most in need of the kind of low learning overhead interface which motivates GUIs or turnkey command frameworks. Plus, semi-related, this project is not doing much right now to facilitate even basic task-oriented scripting; so the limits of what can be done without GUIs are not even in sight yet. I notice the Scripting Overview (in the Doxygen output, technical primers section) has this disturbing statement right at the top: The scripting support is intended for developers of OpenOCD. It is not the intention that normal OpenOCD users will use tcl scripting extensively, write lots of clever scripts, or contribute back to OpenOCD. Well, why the heck should users *NOT* use the scripting? Or contribute? Color me puzzled. Classically, those are the primary reasons to include scripting. And if users don't contribute scripts, how *do* they help grow support for more systems? And how *could* the developers really understand user requirements? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Target AJAX like support - User Interface Thread
duane I think your view is more (A), and mine is more (B). david Yet my example of a flash download tool seems more like (B) to me. :) Seems like we both sit at two different ends of the spectrum, you see de-bricking/flashing a board as day to day I don't. That is perhaps good, it makes one think of the other use cases. If I where to list use case areas of interest - they would be: (a) my board is a brick - please help me reflash(recover) my board type GUI interface. Be it linux or some other operating system - the board is dead and must be recovered. This is more for the linux target board developer type. Also WinCE types, ie: urjtag type solution, and is more flash programmer centric Much of this is External NOR flash,or External NAND flash. What is not - is micro-controller based stuff which is more (d) then (a). Boundary scan method works (ie: the UrJTAG approach) but is slow or the download helper code (the OpenOCD approach) faster. (b) How to write a xlinix flash programer type solution aka: Much like Xilinx IMPACT, or the Altera equal (I don't know the name). This is more jtag centric. I guess this is more Dick Holenbeck type centric (he wrote the xsvf support). (c) Boundary Scan - wiggle pins on the jtag chain. People have asked about this... and we have talked about it But there are no drum beaters eager to help. (d) Debug Software Development solutions. Mostly non-linux-kernel micro controller centric uboot debug falls into this category. === agree? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] endstate command
On Sun, Jun 7, 2009 at 7:45 PM, David Brownelldavi...@pacbell.net wrote: On Sunday 07 June 2009, David Brownell wrote: How about retiring the endstate command? No current in-tree users, FWIW. ... except beagleboard init, sorry. Does that usage happen to be broken anyway? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Retired endstate command
Committed. Retired endstate(and updated docs). Background polling would overwrite any changes to the endstate. From the command line point of with the recent changes to ir/drscan the endstate command wasn't used anyway. The best I can do for the beagleboard config files that use endstate is to let it fail w/a syntax error, because I have no idea what the script expected that command to do and the endstate command probably didn't do what the script writers expected anyway. make pdf(openocd.texi) failed before after the this commit, so I don't know if I broke something. make[1]: Entering directory `/cygdrive/c/workspace/build/doc' TEXINPUTS=../../openocd/doc:$TEXINPUTS \ MAKEINFO='/bin/sh /cygdrive/c/workspace/openocd/missing --run makeinfo -I ../../openocd/doc' \ texi2dvi --pdf --batch ../../openocd/doc/openocd.texi This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4) file:line:error style messages enabled. %-line parsing enabled. ---! /var/lib/texmf/web2c/etex.fmt was written by pdfetex (Fatal format file error; I'm stymied) /usr/bin/texi2dvi: texinfo.tex appears to be broken, quitting. make[1]: *** [openocd.pdf] Error 1 make[1]: Leaving directory `/cygdrive/c/workspace/build/doc' make: *** [pdf-recursive] Error 1 -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] openocd.texi misc cleanup
On Thu, 2009-06-04 at 01:59 -0700, David Brownell wrote: Various minor tweaks for the User's guide. - Fix various minor (but repeated) typographic goofs; - Talk about TAP declaration not creation (they exist even if OpenOCD never learns about their board); - Encourage board.cfg for reset config, not target.cfg - Fill in some missing information (e.g. x16_as_x8) - Add a cross reference to the FAQ on TAP ordering; - Unclutter the concept index a bit (re core-specific commands) - Provide a bit more info about TAP states --- doc/openocd.texi | 193 - 1 file changed, 104 insertions(+), 89 deletions(-) Committed, r2096. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] openocd.texi - final commands (ch12/cpu config)
On Fri, 2009-06-05 at 01:06 -0700, David Brownell wrote: Rework chapter 12 (CPU configuration) to use @deffn, match the code more closely, and present things more clearly. Includes the *current* list of targets. Whew ... this should be the last set of reference matter changes, I think all the commands (except the JTAG adapter ones mentioned earlier) have been reviewed, corrected, and updated. --- doc/openocd.texi | 672 + 1 file changed, 429 insertions(+), 243 deletions(-) Committed, r2097. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Make mdw output readable again
On Thu, 2009-06-04 at 17:34 +0200, Magnus Lundin wrote: Regards Magnus Committed, r2098. Sorry for causing this regression. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] evb_lm3s811 docs
On Fri, 2009-06-05 at 02:55 -0700, David Brownell wrote: Clarify docs for the evb_lm3s811 layout: works in two modes, not just one. --- doc/openocd.texi |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Committed, r2099. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] just ignore disabled targets
On Sat, 2009-06-06 at 19:43 -0700, David Brownell wrote: Let disabled targets be ignored during normal operation: - In target_examine(), ignore disabled TAPs - Reset handling must not poke at them either: * fail $target_name arp_* operations on disabled TAPs * in startup.tcl, don't even issue the arp_* wait ops No other target cleanup included here. --- src/helper/startup.tcl | 28 +++- src/target/target.c| 27 --- 2 files changed, 47 insertions(+), 8 deletions(-) Committed, r2100, with minor tweaks to save future clean-up time. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232H based dongle with adaptive clocking support
On Sun, Jun 07, 2009 at 12:49:49AM +0200, Patrick Wieland wrote: This is my first posting to this mailing list, so I friendly say 'hello' to everyone :-) I am working on a OpenOCD dongle based on the FT2232H. I want to support adaptive clocking, but I don't know how to accomplish this task. AFAIK there are no FT2232 based designs with this feature available. My idea is to measure the frequency on RTCK with an microcontroller and send the value via the 2nd MPSSE device of the FT2232H to OpenOCD. But I think that there had a lot of modifications to the OpenOCD source code to be made to work this way, so my question to is: Is there an easier way? Read the jtag appnote on their site, the info on where rtck should be connected is burried somewhere in there. I found it once, but forgot to write down the exact location. Best regard Rik ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] target list tweaks
TARGET list tweaks:
- Don't let disabled TAPs be set as the current target
- Improve targets output:
* Remove undesirable chain position number; we discourage using them
* TAP and Target column updates:
+ make them long enough for current usage
+ improve labels, removing guesswork
+ TapName label patches scan_chain output
* Highlight the current target
* Display tap disabled as a new pseudo-state
* Update docs accordingly
Sample of the new output:
TargetName Type Endian TapNameState
-- -- -- -- --
0* at91rm9200.cpu arm920tlittle at91rm9200.cpu running
1 MyTarget cortex_m3 little mychip.foo tap-disabled
---
doc/openocd.texi|9 +
src/target/target.c | 33 ++---
2 files changed, 31 insertions(+), 11 deletions(-)
TARGET list tweaks:
- Don't let disabled TAPs be set as the current target
- Improve targets output:
* Remove undesirable chain position number; we discourage using them
* TAP and Target column updates:
+ make them long enough for current usage
+ improve labels, removing guesswork
+ TapName label patches scan_chain output
* Highlight the current target
* Display a tap disabled as a new pseudo-state
* Update docs accordingly
Sample of the new output:
TargetName Type Endian TapNameState
-- -- -- -- --
0* at91rm9200.cpu arm920tlittle at91rm9200.cpu running
1 MyTarget cortex_m3 little mychip.foo tap-disabled
---
doc/openocd.texi|9 +
src/target/target.c | 33 ++---
2 files changed, 31 insertions(+), 11 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -2117,14 +2117,15 @@ You can display the list with the @comma
This display often has only one CPU; here's what it might
look like with more than one:
@verbatim
-CmdNameType Endian AbsChainPos Name State
--- -- -- -- --- - --
- 0: rm9200.cpu arm920tlittle 2 rm9200.cpu running
- 1: MyTarget cortex_m3 little 0 mychip.cpu halted
+TargetName Type Endian TapNameState
+-- -- -- -- --
+ 0* at91rm9200.cpu arm920tlittle at91rm9200.cpu running
+ 1 MyTarget cortex_m3 little mychip.foo tap-disabled
@end verbatim
One member of that list is the @dfn{current target}, which
is implicitly referenced by many commands.
+It's the one marked with a @code{*} near the target name.
In particular, memory addresses often refer to the address
space seen by that current target.
Commands like @command{mdw} (memory display words)
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -1467,6 +1467,12 @@ static int handle_targets_command(struct
command_print(cmd_ctx,Target: %s is unknown, try one of:\n, args[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;
@@ -1474,19 +1480,32 @@ static int handle_targets_command(struct
DumpTargets:
target = all_targets;
- command_print(cmd_ctx, CmdNameType Endian AbsChainPos Name State );
- command_print(cmd_ctx, -- -- -- -- --- - --);
+ command_print(cmd_ctx, TargetName Type Endian TapNameState );
+ command_print(cmd_ctx, -- -- -- -- -- );
while (target)
{
- /* XX: abcdefghij abcdefghij abcdefghij abcdefghij */
- command_print(cmd_ctx, %2d: %-10s %-10s %-10s %10d %14s %s,
+ const char *state;
+ char marker = ' ';
+
+ if (target-tap-enabled)
+ state = Jim_Nvp_value2name_simple(nvp_target_state,
+ target-state)-name;
+ else
+ state = tap-disabled;
+
+ if (cmd_ctx-current_target == target-target_number)
+ marker = '*';
+
+ /* keep columns lined up to match the headers above */
+ command_print(cmd_ctx, %2d%c %-18s %-10s %-6s %-18s %s,
target-target_number,
+ marker,
target-cmd_name,
target_get_name(target),
- Jim_Nvp_value2name_simple( nvp_target_endian, target-endianness )-name,
- target-tap-abs_chain_position,
+ Jim_Nvp_value2name_simple(nvp_target_endian,
+target-endianness)-name,
target-tap-dotted_name,
- Jim_Nvp_value2name_simple( nvp_target_state, target-state )-name );
+ state);
target = target-next;
}
[Openocd-development] [patch] fix $target_name cget -work-area-backup
Bugfix: $target_name cget/configure -work-area-backup commands should return the is it backed up? flag, not the work area size. --- src/target/target.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Bugfix: $target_name cget/configure -work-area-backup commands should return the is it backed up? flag, not the work area size. --- src/target/target.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- oocd.orig/src/target/target.c 2009-06-07 20:54:25.0 -0700 +++ oocd/src/target/target.c 2009-06-07 09:12:15.0 -0700 @@ -3413,7 +3413,7 @@ static int target_configure( Jim_GetOptI goto no_params; } } - Jim_SetResult( interp, Jim_NewIntObj( goi-interp, target-working_area_size ) ); + Jim_SetResult(interp, Jim_NewIntObj(goi-interp, target-backup_working_area)); /* loop for more e*/ break; ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
