Re: [Openocd-development] build issue with current svn trunk
On Sat, May 30, 2009 at 10:08 PM, David Brownell wrote: > On Saturday 30 May 2009, David Brownell wrote: >> On Saturday 30 May 2009, Øyvind Harboe wrote: >> > Why do I need to understand what this does? >> >> You don't. You just need to accept that since you're >> working as a "maintainer", you need to enable that mode. >> >> The alternative is ugly: requiring everyone who builds >> from source to have the *right* versions of all the >> autotools things installed. > > ... where, to clarify, "source" doesn't mean "svn" > (or "git-svn") but "source distribution". Even that varies from project to project: http://gcc.gnu.org/viewcvs/trunk/configure Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dealing with cumulative patches - and patch sets
git has the advantage of having more infrastructure (GUIs for example). But some of the stuff that quilt was designed for is buried in exotic commands in git. 'git help ' brings up the docs, 'git help git' lists all commands. 'git svn clone' creates a local git clone of an svn repo 'git svn rebase' pulls the latest changes from svn; it removes your local commits and re-applies them on top of the newest svn revision 'git stash' lets you stash away changes to the local working dir if you need a clean tree, for example for 'git svn rebase' In git you add all your changes for the next commit to an "index" or "staging area" before you run commit: 'git add' adds changes to the index 'git add -p' is an interactive command allows you to pick individual diff hunks rather than all changes in a file for inclusion in the index 'git commit' turns the changes collected in the index into a commit stuff added to the index doesn't turn up in regular 'git diff' you need 'git diff --cached' (or 'git diff --staged') to show whats in the index 'git reset --mixed' forgets the index while not touching the working dir 'git rebase' allows you to manipulate past commits, re-ordering/merging/splitting (haven't tried the latter) 'git reset --hard ' kills all revisions that were committed after and changes the working dir to (unless you branched) 'gitk' is a gui to browse through the repo and do some things like generating patches 'git-citool' is a gui that supposedly helps you with the whole index/commit thing Michael On Sun, May 31, 2009 at 4:10 AM, David Brownell wrote: > On Saturday 30 May 2009, Peter Denison wrote: >> Quilt. It's exactly the tool to do this. > > Exactly. You're working with a series of patches all > the time, so there's no special step to create one. > > It's also a good way to work with semi-stable snapshots > while you finish stabilizing your work. You develop a > series of "good" modular patches, test, debug, clean up; > updating to a new base snapshot is just reverting all > your patches, making sure the workspace is clean, then > pulling in a new version and re-applying the patches. > (They can need tweaking though.) > > It can also be done with "git" commands, but I've gotten > into the habit of using quilt instead. > > - Dave > ___ > 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] jlink issues
On Sun, May 31, 2009 at 3:25 AM, Peter Denison wrote: > Many thanks! Somehow in my testing (probably to try to replicate XC's > config) I had put jtag_rclk in my .cfg file. > > I've replaced it with jtag_khz 30, and I can at least initialise now. Sorry > for the misdirection. I am guilty here. > So, summary: r1932, J-Link V6, XScale IXP422 target. Initialisation works. > > Now the tcl scripts have moved, I need to work out how to be in the right > directory (src/target) to find the XScale debug handler, and the right > directory (tcl) for "source [find target/ixp42x.cfg]" to work... > Isn't that (tcl scripts moving to to another directory) transparent and require no change to your script? -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dealing with cumulative patches - and patch sets
On Saturday 30 May 2009, Peter Denison wrote: > Quilt. It's exactly the tool to do this. Exactly. You're working with a series of patches all the time, so there's no special step to create one. It's also a good way to work with semi-stable snapshots while you finish stabilizing your work. You develop a series of "good" modular patches, test, debug, clean up; updating to a new base snapshot is just reverting all your patches, making sure the workspace is clean, then pulling in a new version and re-applying the patches. (They can need tweaking though.) It can also be done with "git" commands, but I've gotten into the habit of using quilt instead. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] More reset_config docs
On Saturday 30 May 2009, Øyvind Harboe wrote: > > This would work well with a "disable_rtck" ... when > > a board doesn't support it, it shouldn't be possible > > to try using it even if the adapter does. > > rtck is handled differently: if rtck is not supported, then > setting rtck fails. The tcl code can catch this exception > and deal with it. > > look at the tcl definition of jtag_rtck... Been there, done that. Reread what I wrote: the issue is the *board* not wiring it. The current code to check "is RTCK supported" only addresses the JTAG adapter. There's no way for it to discern the case which I listed: adapter supports it, but board does not. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TMS470 Scripts
On Wed, May 27, 2009 at 2:33 AM, Krzysztof Dziuba wrote: > I attached my cfg file, I think it needs to be polished before including it > to the official configurations, however it works for me. > There is also patch which fix big endian issue. It was created by some other > person and is some kind of magic for me (I have no idea of internal life of > openocd). I don't have little endian target, so I don't know if it will > break support of LE chips. Thanks to the help of Magnus Lundin, I can connect J-Link to the target now with your script and some modifications. https://lists.berlios.de/pipermail/openocd-development/2009-May/007513.html I have not tried flashing (I do not want to brick the board) and real debugging yet (as such, not using the patch). Did you try flashing the TMS470 with OpenOCD? -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Minor fix to J-Link debugging
On Sat, 2009-05-30 at 23:15 +0100, Peter Denison wrote: > The debugging code in jlink_tap_execute() called when > _DEBUG_USB_COMMS_ is > defined was using the entire cached scan length to print the results > buffers, and not the correct length of each individual buffer. Committed, r1955. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Listing BSDL files
On Fri, 2009-05-29 at 11:38 -0300, Alan Carvalho de Assis wrote: > Hi all, > > Follow below links to some BSDL files: > > NXP LPC: > http://www.standardics.nxp.com/support/models/lpc2000/ > > Freescale PowerPC: > http://www.freescale.com/webapp/sps/site/overview.jsp?code=DRPPCBSDLFLS > > Freescale i.MX1 (too old): > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX1&nodeId=0162468rH311432973ZrDR&fpsp=1&tab=Design_Tools_Tab > > Did I forget other BSDL links? Show me the link ;-) Committed, r1954. Patches to doc/manual/primer/jtag.txt to expand this content would be welcome. Better would be patches to support BSDL. :) --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Minor fix to J-Link debugging
The debugging code in jlink_tap_execute() called when _DEBUG_USB_COMMS_ is
defined was using the entire cached scan length to print the results
buffers, and not the correct length of each individual buffer.
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c (revision 1932)
+++ src/jtag/jlink.c (working copy)
@@ -818,7 +818,7 @@
DEBUG_JTAG_IO("pending scan result, length = %d", length);
#ifdef _DEBUG_USB_COMMS_
- jlink_debug_buffer(buffer, byte_length);
+ jlink_debug_buffer(buffer, TAP_SCAN_BYTES(length));
#endif
if (jtag_read_buffer(buffer, command) != ERROR_OK)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] More reset_config docs
On Sat, May 30, 2009 at 10:36 PM, David Brownell wrote: > On Saturday 30 May 2009, Ųyvind Harboe wrote: >> >> So these are *targets* that don't need or want >> >> TRST? >> > >> > In the Atmel case, yes. >> > >> > In the TI case, no. TI boards often come with >> > both "TI-14" and "ARM-20" JTAG connectors. >> > So whether you have SRST depends on which kind >> > of JTAG adapter you use ... not the board, not >> > the CPU. >> >> How about using separate target/board config files to >> handle different connectors on a board? > > No, that's chaos. > > Notice that my "PROPOSAL 2" gave a completely clean > way to handle that: the *JTAG adapter* can veto the > use of a particular signal. So an adapter that talks > "TI-14" could say "disable_srst" ... and when it hooks > up to a board that's correctly setup for "srst_and_trst", > it will work just fine. > > Or in the AVR8 case, tha board might say "disable_trst" > then it won't matter what kind of jtag link is used. > > This would work well with a "disable_rtck" ... when > a board doesn't support it, it shouldn't be possible > to try using it even if the adapter does. rtck is handled differently: if rtck is not supported, then setting rtck fails. The tcl code can catch this exception and deal with it. look at the tcl definition of jtag_rtck... Perhaps something similar for reset_config? The interface would make it fail if the combination isn't supported and then the target config script can try to deal with it? -- Ø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] Dealing with cumulative patches - and patch sets
On Sat, 30 May 2009, Duane Ellis wrote: > All, > (especially david & zach, you seem to do this very well). > > Yes, this is some what "off-topic" for this list, but it is on topic > because the list wants "small more reviewable patches". To that end, I'm > looking for a better way to deal with patch sets, etc. > > I've noticed that for example some post a nice series of 10 patches... > each a minor step... in total quite a lot, and the poster tends to do > all of these patches at once. > > Problem #1. > > > Yea, I can create an SVN patch - from HEAD, but that's not what I'm > looking for. For example - if I have 5 changes to a file, and they are > standalone patches, I do the work 'independently' - ie: change 1 today, > change 2 tomorrow, etc. > > Other then manually editing the resulting "cumulative patch" (a nasty > job) - what better way or tool is there to do this? Quilt. It's exactly the tool to do this. > Problem #2 > > > So those patches are posted... on the list, waiting for stuff, and I > have other things to deal with. Creating the next patch, for a > different file - or set of files is again painfully manual. > > Isn't there some way to say: "Hey patch tool - you already know about > those first 5 changes in Problem #1" please ... assume those are done, > and create my patch file based on that. > > How can I do that? Again, other then manually editing the patch file, or > manually creating crazy command lines to do the diffs/patch generation. Quilt again. http://linux.die.net/man/1/quilt for the man page (without installing it). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Dealing with cumulative patches - and patch sets
All, (especially david & zach, you seem to do this very well). Yes, this is some what "off-topic" for this list, but it is on topic because the list wants "small more reviewable patches". To that end, I'm looking for a better way to deal with patch sets, etc. I've noticed that for example some post a nice series of 10 patches... each a minor step... in total quite a lot, and the poster tends to do all of these patches at once. Problem #1. Yea, I can create an SVN patch - from HEAD, but that's not what I'm looking for. For example - if I have 5 changes to a file, and they are standalone patches, I do the work 'independently' - ie: change 1 today, change 2 tomorrow, etc. Other then manually editing the resulting "cumulative patch" (a nasty job) - what better way or tool is there to do this? Problem #2 So those patches are posted... on the list, waiting for stuff, and I have other things to deal with. Creating the next patch, for a different file - or set of files is again painfully manual. Isn't there some way to say: "Hey patch tool - you already know about those first 5 changes in Problem #1" please ... assume those are done, and create my patch file based on that. How can I do that? Again, other then manually editing the patch file, or manually creating crazy command lines to do the diffs/patch generation. Ideas, suggestions, techniques would be quite helpful for me. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Re: [Openocd-svn] r1949 - in trunk/src/jtag: unused function, jlink
(oops, sent this to the svn-mail list Doh!)
This commit earlier - exposes a now unused function,
Patch attached.
Modified: trunk/src/jtag/jlink.c
===
--- trunk/src/jtag/jlink.c 2009-05-30 07:56:14 UTC (rev 1948)
+++ trunk/src/jtag/jlink.c 2009-05-30 11:37:21 UTC (rev 1949)
@@ -234,7 +234,6 @@
{
switch (cmd->type)
{
- case JTAG_END_STATE: jlink_execute_end_state(cmd); break;
case JTAG_RUNTEST: jlink_execute_runtest(cmd); break;
case JTAG_STATEMOVE: jlink_execute_statemove(cmd); break;
case JTAG_PATHMOVE: jlink_execute_pathmove(cmd); break;
==
Index: openocd.head/src/jtag/jlink.c
===
--- openocd.head/src/jtag/jlink.c (revision 1950)
+++ openocd.head/src/jtag/jlink.c (working copy)
@@ -150,14 +150,7 @@
.quit = jlink_quit
};
-static void jlink_execute_end_state(jtag_command_t *cmd)
-{
- DEBUG_JTAG_IO("end_state: %i", cmd->cmd.end_state->end_state);
- if (cmd->cmd.end_state->end_state != TAP_INVALID)
- jlink_end_state(cmd->cmd.end_state->end_state);
-}
-
static void jlink_execute_runtest(jtag_command_t *cmd)
{
DEBUG_JTAG_IO("runtest %i cycles, end in %i",
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] More reset_config docs
On Saturday 30 May 2009, Øyvind Harboe wrote: > >> So these are *targets* that don't need or want > >> TRST? > > > > In the Atmel case, yes. > > > > In the TI case, no. TI boards often come with > > both "TI-14" and "ARM-20" JTAG connectors. > > So whether you have SRST depends on which kind > > of JTAG adapter you use ... not the board, not > > the CPU. > > How about using separate target/board config files to > handle different connectors on a board? No, that's chaos. Notice that my "PROPOSAL 2" gave a completely clean way to handle that: the *JTAG adapter* can veto the use of a particular signal. So an adapter that talks "TI-14" could say "disable_srst" ... and when it hooks up to a board that's correctly setup for "srst_and_trst", it will work just fine. Or in the AVR8 case, tha board might say "disable_trst" then it won't matter what kind of jtag link is used. This would work well with a "disable_rtck" ... when a board doesn't support it, it shouldn't be possible to try using it even if the adapter does. > It seems to me that we should try to define the simplest > possible options in reset_config on top of which we > build more complex stuff. I'm not clear what you're suggesting. Are you hinting there should be some *other* command that talks about which signals are available? I *was* trying to keep it simple. With a single "go-to" command for most aspects of reset wiring, not two or more (which don't play well with each other). On the other hand, maybe there's merit in the notion of way to declare what JTAG signals exist ... one that isn't limited to the core four (TMS/TCK/TDI/TDO) plus resets (SRST/TRST), but also accomodates various other signals (DBGREQ/DBGACK, EMU0/EMU1, EVTI/EVTO, etc). > If we push *everything* into reset_config, then we end > up with a reset_config command from hell Only if that command is poorly designed and factored. Admittedly, it *started* out that way. But needing two or three different commands to configure the things that "reset_config" claims to handle would seem worse. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] build issue with current svn trunk
On Saturday 30 May 2009, David Brownell wrote: > On Saturday 30 May 2009, Øyvind Harboe wrote: > > Why do I need to understand what this does? > > You don't. You just need to accept that since you're > working as a "maintainer", you need to enable that mode. > > The alternative is ugly: requiring everyone who builds > from source to have the *right* versions of all the > autotools things installed. ... where, to clarify, "source" doesn't mean "svn" (or "git-svn") but "source distribution". ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Saturday 30 May 2009, Xiaofan Chen wrote: > Do you know how to remove the warning? > "Warn : DBGACK set while target was in unknown state. Reset or > initialize target." I consider that to be an initialization bug in the OpenOCD code. One of several, actually ... sorting them all out will take time. It should *NOT* be necessary to reset the target like that. > mc...@ubuntu904:~/Desktop/build/openocd/tms470$ openocd -f tms470r1a256.cfg > Open On-Chip Debugger 0.2.0-in-development (2009-05-30-16:36) svn:1948 > > ... > Info : JTAG tap: tms470r1a256.cpu tap/device found: 0x3100e02f > (Manufacturer: 0x017, Part: 0x100e, Version: 0x3) > Info : JTAG Tap/device matched > Warn : DBGACK set while target was in unknown state. Reset or initialize > target. > target state: halted > target halted in ARM state due to breakpoint, current mode: Supervisor > cpsr: 0x00d3 pc: 0x02b4 > Info : accepting 'telnet' connection from 0 > 30 kHz ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] build issue with current svn trunk
On Saturday 30 May 2009, Øyvind Harboe wrote: > Why do I need to understand what this does? You don't. You just need to accept that since you're working as a "maintainer", you need to enable that mode. The alternative is ugly: requiring everyone who builds from source to have the *right* versions of all the autotools things installed. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svf.c is broken
Why is svf.c modifying cmd_queue_cur_state and cmd_queue_cur_end_state? This must end in tears as that state information belongs to the private parts of jtag.c layer and modifying only the JTAG layer doesn't take the driver into account. Magnus explains a bit below a situation that I *believe* is akin to what happens when SRST is asserted and srst_pulls_trst. Somehow the calling code can know that the JTAG controller is in a different state than the JTAG layer expects. The calling code should then be able to tell the JTAG layer and driver what the actual state is. Is that it? https://lists.berlios.de/pipermail/openocd-development/2009-May/007172.html This patch modifies the broken code in svf.c: https://lists.berlios.de/pipermail/openocd-development/2009-May/007133.html -- Ø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] jlink issues
On Sat, 30 May 2009, Magnus Lundin wrote: > Xiaofan Chen wrote: >> On Sat, May 30, 2009 at 1:01 AM, Peter Denison >> wrote: >> >>> Unfortunately not mine... I still get a 1 returned (instead of a zero) as >>> the error code from EMU_CMD_HW_JTAG3, when I send 8 bits: >>> >>> Debug: 192 667 jlink.c:1095 jlink_debug_buffer(): cf 00 08 00 ff 00 >>> Debug: 194 694 jlink.c:1095 jlink_debug_buffer(): 00 >>> Debug: 196 695 jlink.c:1095 jlink_debug_buffer(): 01 >>> >> >> I got similar problem with r1948 and r1508 for the TMS470R1A256 target >> even though r1508 is supposed to work because of sending 8bits. >> >> And I have no problems with r1948 for the Olimex LPC-P2148. >> >> So it seems to me the target may play a part as well. > It looks like you are using jtag_khz 0, this means adaptive clocking with > the RTCK signal. This work for LPC3148 that has a RTCK signal, but as far as > I can find there is no RTCK singal on the TMS470R1A256. > > For testing interface problem I would suggest, always start with a slow jtag > clock, like jtag_khz 30 or 100. If this works try to increase it. Many thanks! Somehow in my testing (probably to try to replicate XC's config) I had put jtag_rclk in my .cfg file. I've replaced it with jtag_khz 30, and I can at least initialise now. Sorry for the misdirection. So, summary: r1932, J-Link V6, XScale IXP422 target. Initialisation works. Now the tcl scripts have moved, I need to work out how to be in the right directory (src/target) to find the XScale debug handler, and the right directory (tcl) for "source [find target/ixp42x.cfg]" to work... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] build issue with current svn trunk
On Sat, May 30, 2009 at 5:10 PM, Michael Bruck wrote: > My understanding is that usually projects provide pre-generated > configure files so that users who want to build the package on their > system don't need the autotools. A non-maintainer in this context is > someone who just wants to compile the package rather than modify any > code (which would then potentially require a re-run of the autotools). It just seems to me that this questions pops up often enough on the mailing list that if I don't understand this option, then it shouldn't hurt me... Why do I need to understand what this does? I don't know what it does other than generate missing files actually :-) -- Ø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] 0.2.0 Status Update
On Fri, May 29, 2009 at 4:51 PM, Zach Welch wrote: >> >> What about the J-Link issues with various target in the thread "TMS470 >> Scripts"? >> TMS470: >> https://lists.berlios.de/pipermail/openocd-development/2009-May/007391.html Sorry this is a false alarm. The script I got has a problem of not setting the jtag_khz. After setting it to 30khz initially it seems to work now. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Listing BSDL files
Hello Alan, Friday, May 29, 2009, 4:38:55 PM, you wrote: ACdA> Did I forget other BSDL links? Show me the link ;-) http://www.freelabs.com/~whitis/electronics/jtag/ under "Semiconductor Manufacturer's BSDL files" -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Sat, May 30, 2009 at 11:39 PM, Magnus Lundin wrote:
> It looks like you are using jtag_khz 0, this means adaptive clocking with
> the RTCK signal. This work for LPC3148 that has a RTCK signal, but as far as
> I can find there is no RTCK singal on the TMS470R1A256.
>
> For testing interface problem I would suggest, always start with a slow
> jtag clock, like jtag_khz 30 or 100. If this works try to increase it.
>
I did not set jtag_khz. So 0 is the default, right?
Now it works! At least I can connect. Thanks a lot for the tip.
Do you know how to remove the warning?
"Warn : DBGACK set while target was in unknown state. Reset or
initialize target."
mc...@ubuntu904:~/Desktop/build/openocd/tms470$ openocd -f tms470r1a256.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-30-16:36) svn:1948
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
30 kHz
using flash keys 0x, 0x, 0x, 0x
osc_megahertz=12
plldis=0
Error: J-Link command EMU_CMD_VERSION failed (-110)
Info : J-Link ARM V6 compiled Apr 1 2009 11:56:10
Info : JLink caps 0x19ff7bbf
Info : JLink hw version 6
Info : JLink max mem block 8832
Info : Vref = 3.132 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Info : JTAG tap: tms470r1a256.cpu tap/device found: 0x3100e02f
(Manufacturer: 0x017, Part: 0x100e, Version: 0x3)
Info : JTAG Tap/device matched
Warn : DBGACK set while target was in unknown state. Reset or initialize target.
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x00d3 pc: 0x02b4
Info : accepting 'telnet' connection from 0
30 kHz
Info : JTAG tap: tms470r1a256.cpu tap/device found: 0x3100e02f
(Manufacturer: 0x017, Part: 0x100e, Version: 0x3)
Info : JTAG Tap/device matched
^C
mc...@ubuntu904:~$ telnet localhost
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> reset
30 kHz
JTAG tap: tms470r1a256.cpu tap/device found: 0x3100e02f (Manufacturer:
0x017, Part: 0x100e, Version: 0x3)
JTAG Tap/device matched
> Connection closed by foreign host.
Config file:
source [find interface/jlink.cfg]
#--- Daemon Configuration
telnet_port
gdb_port
tcl_port
# Tell gdb that you can use us to program the device (requires GDB
>=6.7 and libexapt)
gdb_memory_mapenable
gdb_flash_program enable
# Start slow, speed up after reset
jtag_khz 30
# TI TMS470R1A384
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME tms470r1a256
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN big
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# force an error till we get a good number
set _CPUTAPID 0x3100e02f
}
jtag_nsrst_delay 200
jtag_ntrst_delay 200
#use combined on interfaces or targets that can't set TRST/SRST separately
#reset_config trst_and_srst
reset_config trst_and_srst srst_pulls_trst
#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf
-expected-id $_CPUTAPID
# The target
set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi
$_TARGETNAME configure -event reset-start {
jtag_khz 30
}
$_TARGETNAME configure -event reset-init {
# Force target into ARM state.
soft_reset_halt
# disable illegal address reset
mww 0xffe0 0x4007
#cs0 flash
mww 0xfe04 0x
mww 0xfe00 0x
#cs1
mww 0xfe08 0x
mww 0xfe0c 0x
#cs2 ram 0x 32k
mww 0xfe10 0x
mww 0xfe14 0x0060
#cs3 ram
mww 0xfe18 0x
mww 0xfe1c 0x
#cs4 het
mww 0xfe20 0x0020
mww 0xfe24 0x0010
# activate new mapping by writing 1 to MFBALR0.8
mww 0xfe04 0x0100
# GCR SYSCLK *4 and /4 = SYSCLK /1
#mww 0xffdc 0x000b
sleep 100
jtag_khz 1500
}
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x0020
-work-area-size 0x4000 -work-area-backup 0
flash bank tms470 0x0 0x2 0 0 0
flash bank tms470 0x2 0x2 0 0 0
flash bank tms470 0x4 0x2 0 0 0
tms470 flash_keyset 0x 0x 0x 0x
tms470 osc_megahertz 12
tms470 plldis 0
--
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
Xiaofan Chen wrote: > On Sat, May 30, 2009 at 1:01 AM, Peter Denison wrote: > >> Unfortunately not mine... I still get a 1 returned (instead of a zero) as >> the error code from EMU_CMD_HW_JTAG3, when I send 8 bits: >> >> Debug: 191 667 jlink.c:1032 jlink_usb_write(): jlink_usb_write, out_length = >> 6, result = 6 >> Debug: 192 667 jlink.c:1095 jlink_debug_buffer(): cf 00 08 00 ff 00 >> Debug: 193 694 jlink.c:1054 jlink_usb_read(): jlink_usb_read, result = 1 >> Debug: 194 694 jlink.c:1095 jlink_debug_buffer(): 00 >> Debug: 195 695 jlink.c:1069 jlink_usb_read_emu_result(): >> jlink_usb_read_result, result = 1 >> Debug: 196 695 jlink.c:1095 jlink_debug_buffer(): 01 >> Error: 197 695 jlink.c:971 jlink_usb_message(): jlink_usb_message failed >> with result=1) >> Error: 198 695 jlink.c:810 jlink_tap_execute(): jlink_tap_execute, wrong >> result -107 (expected 1) >> >> > > I got similar problem with r1948 and r1508 for the TMS470R1A256 target > even though r1508 is supposed to work because of sending 8bits. > > r1948: > Debug: 134 6136 jtag.c:2384 jtag_init_inner(): Init JTAG chain > Debug: 135 6136 jtag.c:413 jtag_call_event_callbacks(): jtag event: > JTAG controller reset (RESET or TRST) > Debug: 136 6136 jtag.c:1630 jtag_reset_callback(): - > Debug: 137 6139 jlink.c:1077 jlink_debug_buffer(): cf 00 07 00 7f 00 > Debug: 138 6166 jlink.c:1077 jlink_debug_buffer(): 00 > Debug: 139 6169 jlink.c:1077 jlink_debug_buffer(): 01 > Error: 140 6169 jlink.c:961 jlink_usb_message(): jlink_usb_message > failed with result=1) > Error: 141 6169 jlink.c:800 jlink_tap_execute(): jlink_tap_execute, > wrong result -107 (expected 1) > > r1508 > Info : 111 94 jlink.c:328 jlink_init(): J-Link JTAG Interface ready > Debug: 112 94 jlink.c:461 jlink_reset(): trst: 0, srst: 0 > Debug: 113 94 jlink.c:964 jlink_debug_buffer(): dd > Debug: 114 98 jlink.c:964 jlink_debug_buffer(): df > Debug: 115 101 jlink.c:964 jlink_debug_buffer(): 05 ff ff > Debug: 116 102 openocd.c:144 handle_init_command(): jtag interface init > complete > Debug: 117 102 jtag.c:2201 jtag_init_inner(): Init JTAG chain > Debug: 118 102 jtag.c:390 jtag_call_event_callbacks(): jtag event: > JTAG controller reset (RESET or TRST) > Debug: 119 102 jtag.c:1450 jtag_reset_callback(): - > Debug: 120 104 jlink.c:964 jlink_debug_buffer(): cf 00 08 00 ff 00 > Debug: 121 132 jlink.c:964 jlink_debug_buffer(): 00 > Debug: 122 135 jlink.c:964 jlink_debug_buffer(): 01 > Error: 123 135 jlink.c:844 jlink_usb_message(): jlink_usb_message > failed with result=1) > Error: 124 135 jlink.c:704 jlink_tap_execute(): jlink_tap_execute, > wrong result -107 (expected 1) > Debug: 125 135 jtag.c:2234 jtag_init_reset(): Trying to bring the JTAG > controller to life by asserting TRST / RESET > > And I have no problems with r1948 for the Olimex LPC-P2148. > Info : 99 102 jlink.c:350 jlink_init(): J-Link JTAG Interface ready > Debug: 100 102 jlink.c:488 jlink_reset(): trst: 0, srst: 0 > Debug: 101 103 jlink.c:1077 jlink_debug_buffer(): dd > Debug: 102 106 jlink.c:1077 jlink_debug_buffer(): df > Debug: 103 116 jlink.c:1077 jlink_debug_buffer(): 05 ff ff > Debug: 104 116 openocd.c:138 handle_init_command(): jtag interface init > complete > Debug: 105 116 jtag.c:2384 jtag_init_inner(): Init JTAG chain > Debug: 106 116 jtag.c:413 jtag_call_event_callbacks(): jtag event: > JTAG controller reset (RESET or TRST) > Debug: 107 116 jtag.c:1630 jtag_reset_callback(): - > Debug: 108 119 jlink.c:1077 jlink_debug_buffer(): cf 00 07 00 7f 00 > Debug: 109 120 jlink.c:1077 jlink_debug_buffer(): 00 > Debug: 110 123 jlink.c:1077 jlink_debug_buffer(): 00 > Debug: 111 123 jtag.c:413 jtag_call_event_callbacks(): jtag event: > JTAG controller reset (RESET or TRST) > Debug: 112 123 jtag.c:1630 jtag_reset_callback(): - > Debug: 113 124 jlink.c:1077 jlink_debug_buffer(): ff 00 00 00 ff > 00 00 00 ff 00 00 00 ff 00 00 00 > Debug: 114 124 jlink.c:1077 jlink_debug_buffer(): 0010 ff 00 00 00 ff > 00 00 00 ff 00 00 00 ff 00 00 00 > Debug: 115 124 jlink.c:1077 jlink_debug_buffer(): 0020 ff 00 00 00 ff > 00 00 00 ff 00 00 00 ff 00 00 00 > Debug: 116 124 jlink.c:1077 jlink_debug_buffer(): 0030 ff 00 00 00 ff > 00 00 00 ff 00 00 00 ff 00 00 00 > Debug: 117 124 jlink.c:1077 jlink_debug_buffer(): 0040 ff 00 00 00 ff > 00 00 00 ff 00 00 00 ff 00 00 00 > Debug: 118 126 jlink.c:1077 jlink_debug_buffer(): cf 00 8f 02 17 > 00 00 00 00 00 00 00 00 00 00 00 > Debug: 119 126 jlink.c:1077 jlink_debug_buffer(): 0010 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 > Debug: 120 127 jlink.c:1077 jlink_debug_buffer(): 0020 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 > Debug: 121 127 jlink.c:1077 jlink_debug_buffer(): 0030 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 > Debug: 122 127 jlink.c:1077 jlink_debug_buffer(): 0040 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 > Debug: 123 127 jlink.c:1077 jlink_debug_buffer(): 0050
Re: [Openocd-development] build issue with current svn trunk
My understanding is that usually projects provide pre-generated configure files so that users who want to build the package on their system don't need the autotools. A non-maintainer in this context is someone who just wants to compile the package rather than modify any code (which would then potentially require a re-run of the autotools). Michael On Sat, May 30, 2009 at 9:58 AM, Øyvind Harboe wrote: >> You need to pass --enable-maintainer-mode to configure. > > Why isn't enable-maintainer-mode the default? > > I don't know what this option does really, but this should only be disabled > when making releases, right? > > -- > Ø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 mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Sat, May 30, 2009 at 1:01 AM, Peter Denison wrote: > Unfortunately not mine... I still get a 1 returned (instead of a zero) as > the error code from EMU_CMD_HW_JTAG3, when I send 8 bits: > > Debug: 191 667 jlink.c:1032 jlink_usb_write(): jlink_usb_write, out_length = > 6, result = 6 > Debug: 192 667 jlink.c:1095 jlink_debug_buffer(): cf 00 08 00 ff 00 > Debug: 193 694 jlink.c:1054 jlink_usb_read(): jlink_usb_read, result = 1 > Debug: 194 694 jlink.c:1095 jlink_debug_buffer(): 00 > Debug: 195 695 jlink.c:1069 jlink_usb_read_emu_result(): > jlink_usb_read_result, result = 1 > Debug: 196 695 jlink.c:1095 jlink_debug_buffer(): 01 > Error: 197 695 jlink.c:971 jlink_usb_message(): jlink_usb_message failed with > result=1) > Error: 198 695 jlink.c:810 jlink_tap_execute(): jlink_tap_execute, wrong > result -107 (expected 1) > I got similar problem with r1948 and r1508 for the TMS470R1A256 target even though r1508 is supposed to work because of sending 8bits. r1948: Debug: 134 6136 jtag.c:2384 jtag_init_inner(): Init JTAG chain Debug: 135 6136 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 136 6136 jtag.c:1630 jtag_reset_callback(): - Debug: 137 6139 jlink.c:1077 jlink_debug_buffer(): cf 00 07 00 7f 00 Debug: 138 6166 jlink.c:1077 jlink_debug_buffer(): 00 Debug: 139 6169 jlink.c:1077 jlink_debug_buffer(): 01 Error: 140 6169 jlink.c:961 jlink_usb_message(): jlink_usb_message failed with result=1) Error: 141 6169 jlink.c:800 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) r1508 Info : 111 94 jlink.c:328 jlink_init(): J-Link JTAG Interface ready Debug: 112 94 jlink.c:461 jlink_reset(): trst: 0, srst: 0 Debug: 113 94 jlink.c:964 jlink_debug_buffer(): dd Debug: 114 98 jlink.c:964 jlink_debug_buffer(): df Debug: 115 101 jlink.c:964 jlink_debug_buffer(): 05 ff ff Debug: 116 102 openocd.c:144 handle_init_command(): jtag interface init complete Debug: 117 102 jtag.c:2201 jtag_init_inner(): Init JTAG chain Debug: 118 102 jtag.c:390 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 119 102 jtag.c:1450 jtag_reset_callback(): - Debug: 120 104 jlink.c:964 jlink_debug_buffer(): cf 00 08 00 ff 00 Debug: 121 132 jlink.c:964 jlink_debug_buffer(): 00 Debug: 122 135 jlink.c:964 jlink_debug_buffer(): 01 Error: 123 135 jlink.c:844 jlink_usb_message(): jlink_usb_message failed with result=1) Error: 124 135 jlink.c:704 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) Debug: 125 135 jtag.c:2234 jtag_init_reset(): Trying to bring the JTAG controller to life by asserting TRST / RESET And I have no problems with r1948 for the Olimex LPC-P2148. Info : 99 102 jlink.c:350 jlink_init(): J-Link JTAG Interface ready Debug: 100 102 jlink.c:488 jlink_reset(): trst: 0, srst: 0 Debug: 101 103 jlink.c:1077 jlink_debug_buffer(): dd Debug: 102 106 jlink.c:1077 jlink_debug_buffer(): df Debug: 103 116 jlink.c:1077 jlink_debug_buffer(): 05 ff ff Debug: 104 116 openocd.c:138 handle_init_command(): jtag interface init complete Debug: 105 116 jtag.c:2384 jtag_init_inner(): Init JTAG chain Debug: 106 116 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 107 116 jtag.c:1630 jtag_reset_callback(): - Debug: 108 119 jlink.c:1077 jlink_debug_buffer(): cf 00 07 00 7f 00 Debug: 109 120 jlink.c:1077 jlink_debug_buffer(): 00 Debug: 110 123 jlink.c:1077 jlink_debug_buffer(): 00 Debug: 111 123 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 112 123 jtag.c:1630 jtag_reset_callback(): - Debug: 113 124 jlink.c:1077 jlink_debug_buffer(): ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 Debug: 114 124 jlink.c:1077 jlink_debug_buffer(): 0010 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 Debug: 115 124 jlink.c:1077 jlink_debug_buffer(): 0020 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 Debug: 116 124 jlink.c:1077 jlink_debug_buffer(): 0030 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 Debug: 117 124 jlink.c:1077 jlink_debug_buffer(): 0040 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 Debug: 118 126 jlink.c:1077 jlink_debug_buffer(): cf 00 8f 02 17 00 00 00 00 00 00 00 00 00 00 00 Debug: 119 126 jlink.c:1077 jlink_debug_buffer(): 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Debug: 120 127 jlink.c:1077 jlink_debug_buffer(): 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Debug: 121 127 jlink.c:1077 jlink_debug_buffer(): 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Debug: 122 127 jlink.c:1077 jlink_debug_buffer(): 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Debug: 123 127 jlink.c:1077 jlink_debug_buffer(): 0050 00 00 00 00 40 7f 80 7f 00 00 80 7f 00 00 80 7f Debug: 124 127 jlink.c:1077 jlink_debug_buffer(): 0060 00 00 80 7f 00 00 80 7f 00 00 80 7f 00 00 80 7f Debug: 125 127 jlink.c:1077 jlink_debug_buffer(): 0070
Re: [Openocd-development] On Resets
2009/5/30 Igor Skochinsky : > Hello Øyvind, > > Saturday, May 30, 2009, 9:40:54 AM, you wrote: > >>> than just "conform to JTAG spec". No problem when >>> docs are available ... but sometimes they aren't. > ØH> XScale is under Marvell NDA for instance :-) > Really? What's this then? OK, so *some* XScale docs are available. But whether *all* are published would be under Marvell NDA :-) -- Ø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] [patch] remove unused code TAP_INVALID is never passed to drivers
remove unused check on TAP_INVALID. This value is never passed to drivers.
Comments?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Index: C:/workspace/openocd/src/jtag/ft2232.c
===
--- C:/workspace/openocd/src/jtag/ft2232.c (revision 1949)
+++ C:/workspace/openocd/src/jtag/ft2232.c (working copy)
@@ -512,7 +512,6 @@
}
}
-
static void ft2232_read_scan(enum scan_type type, u8* buffer, int scan_size)
{
int num_bytes = (scan_size + 7) / 8;
@@ -1412,20 +1411,6 @@
LOG_DEBUG("trst: %i, srst: %i, high_output: 0x%2.2x, high_direction:
0x%2.2x", trst, srst, high_output, high_direction);
}
-static int ft2232_execute_end_state(jtag_command_t *cmd)
-{
- int retval;
- retval = ERROR_OK;
-
- DEBUG_JTAG_IO("execute_end_state: %s",
tap_state_name(cmd->cmd.end_state->end_state) );
-
- if (cmd->cmd.end_state->end_state != TAP_INVALID)
- ft2232_end_state(cmd->cmd.end_state->end_state);
-
- return retval;
-}
-
-
static int ft2232_execute_runtest(jtag_command_t *cmd)
{
int retval;
@@ -1682,7 +1667,6 @@
switch (cmd->type)
{
- case JTAG_END_STATE:retval = ft2232_execute_end_state(cmd); break;
case JTAG_RESET:retval =
ft2232_execute_reset(cmd); break;
case JTAG_RUNTEST: retval = ft2232_execute_runtest(cmd); break;
case JTAG_STATEMOVE:retval = ft2232_execute_statemove(cmd); break;
Index: C:/workspace/openocd/src/jtag/jtag.h
===
--- C:/workspace/openocd/src/jtag/jtag.h(revision 1949)
+++ C:/workspace/openocd/src/jtag/jtag.h(working copy)
@@ -348,7 +348,6 @@
JTAG_STATEMOVE= 2,
JTAG_RUNTEST = 3,
JTAG_RESET= 4,
- JTAG_END_STATE= 5,
JTAG_PATHMOVE = 6,
JTAG_SLEEP= 7,
JTAG_STABLECLOCKS = 8
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
Hello Øyvind, Saturday, May 30, 2009, 9:40:54 AM, you wrote: >> than just "conform to JTAG spec". No problem when >> docs are available ... but sometimes they aren't. ØH> XScale is under Marvell NDA for instance :-) Really? What's this then? http://www.marvell.com/products/cellular/application/PXA27x.jsp http://www.marvell.com/products/cellular/application/PXA3xx_series.jsp Also, Intel still has some XScale docs on their site. E.g. Intel XScale® Core Developer’s Manual: http://download.intel.com/design/intelxscale/27347302.pdf Some others can be found mirrored elsewhere: http://www.penguin.cz/~utx/zaurus/datasheets/CPU/ -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] More reset_config docs
On Sat, May 30, 2009 at 2:01 PM, David Brownell wrote: > On Saturday 30 May 2009, Řyvind Harboe wrote: >> I see that I've jumped into a discussion where you are much >> more up to date on the overall reset_config, how to write >> quality documentation, etc. Below are some comments >> where I had any. >> >> Q: What's a "system configuration file"? >> >> I can think of interface config files, target config files, board >> config files, the users config file > > I had to coin a phrase. An example of a system config > file would be "openocd.cfg" ... basic template > > source [find interface/...cfg] > source [find board/...cfg] > ... define task and environment specific utilities ... > > You may be using "user's config file" in a similar way. > I didn't notice that term being defined anywhere either! :-) >> >> + >> >> +If you have an interface that does not support SRST and >> >> +TRST(unlikely), >> > >> > Not unlikely at all. The 14-pin JTAG connectors >> > that TI uses don't pass SRST. The 10-pin JTAG >> > connectors that Atmel uses with AVR8 (and AVR32) >> > chips don't pass TRST. (Although there's a pin >> > reserved for TRST. It's unclear if *any* JTAG >> > adapters use that, since the only chips supporting >> > that signal are the unclear-future AVR32 AP7s.) >> >> So these are *targets* that don't need or want >> TRST? > > In the Atmel case, yes. > > In the TI case, no. TI boards often come with > both "TI-14" and "ARM-20" JTAG connectors. > So whether you have SRST depends on which kind > of JTAG adapter you use ... not the board, not > the CPU. How about using separate target/board config files to handle different connectors on a board? It seems to me that we should try to define the simplest possible options in reset_config on top of which we build more complex stuff. If we push *everything* into reset_config, then we end up with a reset_config command from hell >> I don't understand how one could infer that srst >> is tied to trst by specifying trst_disable... > > Huh? Me either. I don't think I said or even > implied any such thing; where did that come from? I don't know what a trst_disable would do, so I was just guessing/postulating some behaviour. >> W.r.t. #3 I'm not keen because it's nice to be able >> to tinker with various combinations from telnet instead >> of having to "reboot" the system... > > I had thought about that. Such tinkering would only > make sense when experimenting to find an initial working > config, or so I concluded. Ever afterwards, you would > not need to tinker. Generally I'd to support telnet tinkering with options rather than requiring a reboot. JTAG/hardware debugger + telnet *IS* tinkering :-) -- Ø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] More reset_config docs
On Sat, May 30, 2009 at 8:01 PM, David Brownell wrote: >> >> +If you have an interface that does not support SRST and >> >> +TRST(unlikely), >> > >> > Not unlikely at all. The 14-pin JTAG connectors >> > that TI uses don't pass SRST. The 10-pin JTAG >> > connectors that Atmel uses with AVR8 (and AVR32) >> > chips don't pass TRST. (Although there's a pin >> > reserved for TRST. It's unclear if *any* JTAG >> > adapters use that, since the only chips supporting >> > that signal are the unclear-future AVR32 AP7s.) >> >> So these are *targets* that don't need or want >> TRST? > > In the Atmel case, yes. > > In the TI case, no. TI boards often come with > both "TI-14" and "ARM-20" JTAG connectors. > So whether you have SRST depends on which kind > of JTAG adapter you use ... not the board, not > the CPU. > http://focus.ti.com/lit/ug/spnu250/spnu250.pdf I just checked the schematics of the IAR TMS470R1A256 schematics and it comes with both TI-14 and ARM-20 JTAG connectors. There is a TRST pin (pin 2) on the TI-14 pin connector. I do not see the SRST line. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] More reset_config docs
On Saturday 30 May 2009, Øyvind Harboe wrote:
> I see that I've jumped into a discussion where you are much
> more up to date on the overall reset_config, how to write
> quality documentation, etc. Below are some comments
> where I had any.
>
> Q: What's a "system configuration file"?
>
> I can think of interface config files, target config files, board
> config files, the users config file
I had to coin a phrase. An example of a system config
file would be "openocd.cfg" ... basic template
source [find interface/...cfg]
source [find board/...cfg]
... define task and environment specific utilities ...
You may be using "user's config file" in a similar way.
I didn't notice that term being defined anywhere either!
> >> +
> >> +If you have an interface that does not support SRST and
> >> +TRST(unlikely),
> >
> > Not unlikely at all. The 14-pin JTAG connectors
> > that TI uses don't pass SRST. The 10-pin JTAG
> > connectors that Atmel uses with AVR8 (and AVR32)
> > chips don't pass TRST. (Although there's a pin
> > reserved for TRST. It's unclear if *any* JTAG
> > adapters use that, since the only chips supporting
> > that signal are the unclear-future AVR32 AP7s.)
>
> So these are *targets* that don't need or want
> TRST?
In the Atmel case, yes.
In the TI case, no. TI boards often come with
both "TI-14" and "ARM-20" JTAG connectors.
So whether you have SRST depends on which kind
of JTAG adapter you use ... not the board, not
the CPU.
> I was referring to the interface not supporting
> TRST.
Couldn't tell ... :)
It's the same sort of issue though: one of the
signals is not passed through.
Other examples include RTCK, DBG{REQ,ACK}, EMU{0,1},
EVTO, and surely more...
> I don't understand how one could infer that srst
> is tied to trst by specifying trst_disable...
Huh? Me either. I don't think I said or even
implied any such thing; where did that come from?
> W.r.t. #3 I'm not keen because it's nice to be able
> to tinker with various combinations from telnet instead
> of having to "reboot" the system...
I had thought about that. Such tinkering would only
make sense when experimenting to find an initial working
config, or so I concluded. Ever afterwards, you would
not need to tinker.
> I'm also not entirely
> convinced that reset scripts might need to tinker with
> reset_config options during reset itself(seems far-fetch
> today though).
If they need such tinkering, that says to me that
something more complicated is going on ... so the
current "reset_config" is not a good answer. But
since there's no current need for such messiness,
that is not a a good reason not to adopt #3.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] remove unused JTAG_END_STATE
Committed 1950
Remove JTAG_END_STATE entirely.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Index: C:/workspace/openocd/src/jtag/ft2232.c
===
--- C:/workspace/openocd/src/jtag/ft2232.c (revision 1949)
+++ C:/workspace/openocd/src/jtag/ft2232.c (working copy)
@@ -512,7 +512,6 @@
}
}
-
static void ft2232_read_scan(enum scan_type type, u8* buffer, int scan_size)
{
int num_bytes = (scan_size + 7) / 8;
@@ -1412,20 +1411,6 @@
LOG_DEBUG("trst: %i, srst: %i, high_output: 0x%2.2x, high_direction:
0x%2.2x", trst, srst, high_output, high_direction);
}
-static int ft2232_execute_end_state(jtag_command_t *cmd)
-{
- int retval;
- retval = ERROR_OK;
-
- DEBUG_JTAG_IO("execute_end_state: %s",
tap_state_name(cmd->cmd.end_state->end_state) );
-
- if (cmd->cmd.end_state->end_state != TAP_INVALID)
- ft2232_end_state(cmd->cmd.end_state->end_state);
-
- return retval;
-}
-
-
static int ft2232_execute_runtest(jtag_command_t *cmd)
{
int retval;
@@ -1682,7 +1667,6 @@
switch (cmd->type)
{
- case JTAG_END_STATE:retval = ft2232_execute_end_state(cmd); break;
case JTAG_RESET:retval =
ft2232_execute_reset(cmd); break;
case JTAG_RUNTEST: retval = ft2232_execute_runtest(cmd); break;
case JTAG_STATEMOVE:retval = ft2232_execute_statemove(cmd); break;
Index: C:/workspace/openocd/src/jtag/jtag.h
===
--- C:/workspace/openocd/src/jtag/jtag.h(revision 1949)
+++ C:/workspace/openocd/src/jtag/jtag.h(working copy)
@@ -348,7 +348,6 @@
JTAG_STATEMOVE= 2,
JTAG_RUNTEST = 3,
JTAG_RESET= 4,
- JTAG_END_STATE= 5,
JTAG_PATHMOVE = 6,
JTAG_SLEEP= 7,
JTAG_STABLECLOCKS = 8
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] remove unused JTAG_END_STATE
Committed 1949. Splitting the patch into two. Next I'll look into removing this from jtag.h and ft2232.c -- Ø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] More reset_config docs
Oh and obviously if you have patches on this to correct any mistakes I made then I'll be happy to apply them. :-) I just wanted to get something into the docs about that we can not actually know what TRST and SRST does and whether or not the interface supports it is really a problem that OpenOCD does not try to address much. -- Ø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] More reset_config docs
I see that I've jumped into a discussion where you are much more up to date on the overall reset_config, how to write quality documentation, etc. Below are some comments where I had any. Q: What's a "system configuration file"? I can think of interface config files, target config files, board config files, the users config file >> + >> +If you have an interface that does not support SRST and >> +TRST(unlikely), > > Not unlikely at all. The 14-pin JTAG connectors > that TI uses don't pass SRST. The 10-pin JTAG > connectors that Atmel uses with AVR8 (and AVR32) > chips don't pass TRST. (Although there's a pin > reserved for TRST. It's unclear if *any* JTAG > adapters use that, since the only chips supporting > that signal are the unclear-future AVR32 AP7s.) So these are *targets* that don't need or want TRST? I was referring to the interface not supporting TRST. I don't understand how one could infer that srst is tied to trst by specifying trst_disable... W.r.t. #3 I'm not keen because it's nice to be able to tinker with various combinations from telnet instead of having to "reboot" the system... I'm also not entirely convinced that reset scripts might need to tinker with reset_config options during reset itself(seems far-fetch today though). -- Ø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] More reset_config docs
On Saturday 30 May 2009, Øyvind Harboe wrote:
> Committed.
>
> Some more comments on reset_config and why it has the options
> it has.
>
>
> Index: C:/workspace/openocd/doc/openocd.texi
> ===
> --- C:/workspace/openocd/doc/openocd.texi (revision 1946)
> +++ C:/workspace/openocd/doc/openocd.texi (working copy)
> @@ -1699,7 +1699,20 @@
>
> @deffn {Command} reset_config mode_flag ...
> This command tells OpenOCD the reset configuration
> -of your combination of JTAG interface, board, and target.
> +of your combination of JTAG board and target in target
> +configuration scripts.
But it's *not* limited to configuration scripts; see my
previous "PROPOSAL 3":
https://lists.berlios.de/pipermail/openocd-development/2009-May/007318.html
#1 is now merged. If this gets restricted to config
scripts this should become a "{Config Command}".
And I think it's incorrect to imply that there is any
other command for saying that an interface doesn't
pass, for example, SRST (by removing "interface"
from the above text).
> +
> +If you have an interface that does not support SRST and
> +TRST(unlikely),
Not unlikely at all. The 14-pin JTAG connectors
that TI uses don't pass SRST. The 10-pin JTAG
connectors that Atmel uses with AVR8 (and AVR32)
chips don't pass TRST. (Although there's a pin
reserved for TRST. It's unclear if *any* JTAG
adapters use that, since the only chips supporting
that signal are the unclear-future AVR32 AP7s.)
Ergo my "PROPOSAL 2" (see URL above).
> then you may be able to work around that
> +problem by using a reset_config command to override any
> +settings in the target configuration script.
A point that's already made in the NOTE: at the top of
that chapter: "... when the JTAG adapter doesn’t support
everything, the system configuration file will need to
override parts of the reset configuration provided by
other files."
> +
> +SRST and TRST has a fairly well understood definition and
More correctly: "have fairly ... definitions ..." ;)
> +behaviour in the JTAG specification, but vendors take
> +liberties to achieve various more or less clearly understood
> +goals. Sometimes documentation is available, other times it
> +is not. OpenOCD has the reset_config command to allow OpenOCD
> +to deal with the various common cases.
IMO none of that text belongs in the description of what
the "reset_config" command itself does. Explanations and
motivations belong in "big picture" text ... like the
subsection immediately preceding this. And some of that
information already *is* included; see the tail end of
that preceding subsection.
One thing I'm trying to do with the docs is to improve
the quality, and part of that is focussing the command
descriptions on just describing "what" they do.
The other parts of the classic reportial "five W's"
(who, what, when, where, why ... and sometimes "how")
belong in text other than the command descriptions.
That implies a bit more effort to couple those kinds
of explanations with the rest of the story, but that's
exactly what's needed for good documentation.
- Dave
>
> The @var{mode_flag} options can be specified in any order, but only one
> of each type -- @var{signals}, @var{combination}, @var{trst_type},
>
>
> --
> Ø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 mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove cmd_queue_cur_state
I need to look into details, but I believe that this breaks synchronous execution of JTAG calls (for hardware implementations of JTAG FIFOs). I believe this is what Dick was trying to point out, but I need more time to look into this. -- Ø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] A real question about tap states
On Tue, May 26, 2009 at 12:21 AM, Magnus Lundin wrote: > To move the discussion onto something that miqht require a bit o f real > analysis: > > Why does some targets work better during "reset halt" when the > TAP_RESET-> IR_SHIFT is B8(0011000,7) instead of B8(0011011,7) . > > And the hard question: why does the first variant work for the ft2232 > driver when the JLink driver needs the second, for the same target. > > I have recently tried so many variants that my head is spinning. Perhaps it is a red herring? Could it be a bug in the lower levels that is hidden by using a slightly different sequence? Have you tried with a bitbang adapter? -- Ø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] build issue with current svn trunk
> You need to pass --enable-maintainer-mode to configure. Why isn't enable-maintainer-mode the default? I don't know what this option does really, but this should only be disabled when making releases, right? -- Ø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] More reset_config docs
Committed.
Some more comments on reset_config and why it has the options
it has.
Index: C:/workspace/openocd/doc/openocd.texi
===
--- C:/workspace/openocd/doc/openocd.texi (revision 1946)
+++ C:/workspace/openocd/doc/openocd.texi (working copy)
@@ -1699,7 +1699,20 @@
@deffn {Command} reset_config mode_flag ...
This command tells OpenOCD the reset configuration
-of your combination of JTAG interface, board, and target.
+of your combination of JTAG board and target in target
+configuration scripts.
+
+If you have an interface that does not support SRST and
+TRST(unlikely), then you may be able to work around that
+problem by using a reset_config command to override any
+settings in the target configuration script.
+
+SRST and TRST has a fairly well understood definition and
+behaviour in the JTAG specification, but vendors take
+liberties to achieve various more or less clearly understood
+goals. Sometimes documentation is available, other times it
+is not. OpenOCD has the reset_config command to allow OpenOCD
+to deal with the various common cases.
The @var{mode_flag} options can be specified in any order, but only one
of each type -- @var{signals}, @var{combination}, @var{trst_type},
--
Ø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] shut up GDB debugging when no GDB connections are used
This looks good to me. I'm not sure what a good long term solution might be. A requirement/goal of OpenOCD is that it should "just work" with the default settings when using "monitor" commands w/GDB. Really this warning is a reminder to OpenOCD developers to fix the code so "monitor XXX" commands and the like do not cause errors with the default "set remotetimeout 2" that GDB has. OpenOCD is currently single threaded so sending keep alive messages is tedious... pthreads is a new can of works entirely, but perhaps it *would* be a good idea introduce some multithreaded capabilities in OpenOCD? -- Ø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] On Resets
On Fri, May 29, 2009 at 12:14 AM, David Brownell wrote: > On Thursday 28 May 2009, Ųyvind Harboe wrote: >> In the mists of time SRST & TRST probably had some >> well defined function and meaning. > > I think they still *do* ... but it seems vendors > have felt free to play with at least TAP resets in > ways that prevent tools that conform only to JTAG > specs from working as desired. Precisely. OpenOCD has a reset_config command that target config scripts can use to deal with these messy practicalities. > than just "conform to JTAG spec". No problem when > docs are available ... but sometimes they aren't. XScale is under Marvell NDA for instance :-) -- Ø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
