Re: [Openocd-development] proc jtag_init {}
Here is a set of commands that reproduces my problem.
While I agree with David about -c and -f bug, this is a different one.
# Ubuntu 9.04
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
cd ./openocd
./bootstrap
./configure --enable-maintainer-mode --enable-dummy
make
cd src
# The line does not fail
./openocd -s ../tcl/target/ -f ../tcl/target/telo.cfg -c 'interface
dummy' --debug 3 -c proc jtag_init {} {jtag arp_init-reset}
# This line does fail
./openocd -s ../tcl/target/ -f ../tcl/target/telo.cfg -c 'interface
dummy' --debug 3 -c proc jtag_init {} {jtag arp_init-reset if { [info
exists RESET_ME] } {jtag arp_init-reset}}
No modifications to any files are required.
On Mon, 2009-10-19 at 21:13 +0200, Øyvind Harboe wrote:
does not work. It looks like the 'if' statement break things. It does
not matter whether RESET_ON_INIT is defined or not.
I run openocd with:
./openocd -c 'interface dummy' -f telo.cfg -c set RESET_ON_INIT 1
--debug 3
It looks like you've run into a somewhat subtle bug and I can't reproduce
it here.
Could you provide *all and the exact* steps including but not limited
to, building, current directory when you invoke openocd, the unmodified
config script(I had to modify telo.cfg to make it run), etc.
Hopefully I'll be able to reproduce it here and work on it from there...
(The alternative to reproducing fixing it now is of course that it will
crop up at a very inconvenient time...)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] SVF: better spec conformance for STATE switch
Don't add extra TCK in current state; exit from RESET had four extras.
Only IDLE -- IDLE needs such an extra clock. (At least one TCK must
be issued.)
Allow entry to RESET; SVF allows it, so must we (despite those entries
being commented out of the statemove table).
When entering RESET, always use TLR ... we might end up with extra clocks
in reset that way, which is harmless, but we'll never end up in any other
state than RESET, which is useful paranoia.
---
src/svf/svf.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
--- a/src/svf/svf.c
+++ b/src/svf/svf.c
@@ -316,30 +316,28 @@ static int svf_add_statemove(tap_state_t
tap_state_t state_from = cmd_queue_cur_state;
uint8_t index;
+ /* when resetting, be paranoid and ignore current state */
+ if (state_to == TAP_RESET) {
+ jtag_add_tlr();
+ return ERROR_OK;
+ }
+
for (index = 0; index dimof(svf_statemoves); index++)
{
if ((svf_statemoves[index].from == state_from)
(svf_statemoves[index].to == state_to))
{
- if (TAP_RESET == state_from)
- {
- jtag_add_tlr();
- if (svf_statemoves[index].num_of_moves 1)
- {
-
jtag_add_pathmove(svf_statemoves[index].num_of_moves - 1,
svf_statemoves[index].paths + 1);
- }
- }
+ /* recorded path includes current state ... avoid extra
TCKs! */
+ if (svf_statemoves[index].num_of_moves 1)
+
jtag_add_pathmove(svf_statemoves[index].num_of_moves - 1,
+ svf_statemoves[index].paths +
1);
else
- {
- if (svf_statemoves[index].num_of_moves 0)
- {
-
jtag_add_pathmove(svf_statemoves[index].num_of_moves,
svf_statemoves[index].paths);
- }
- }
+
jtag_add_pathmove(svf_statemoves[index].num_of_moves,
+ svf_statemoves[index].paths);
return ERROR_OK;
}
}
- LOG_ERROR(can not move to %s, tap_state_svf_name(state_to));
+ LOG_ERROR(SVF: can not move to %s, tap_state_svf_name(state_to));
return ERROR_FAIL;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] jtag_add_statemove() always uses TLR to get to RESET
As decided a while back, this isn't a transition we want to chance.
Whenever someone wants to got to RESET, force it.
---
Still depends on the JTAG adapter to get it right though, which
many don't. (FT2232 does now.)
src/jtag/core.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -567,12 +567,14 @@ int jtag_add_statemove(tap_state_t goal_
tap_state_name(goal_state));
- if (goal_state == cur_state)
- ; /* nothing to do */
- else if (goal_state == TAP_RESET)
- {
+ /* If goal is RESET, be paranoid and force that that transition
+* (e.g. five TCK cycles, TMS high). Else trust cur_state.
+*/
+ if (goal_state == TAP_RESET)
jtag_add_tlr();
- }
+ else if (goal_state == cur_state)
+ /* nothing to do */ ;
+
else if (tap_is_state_stable(cur_state)
tap_is_state_stable(goal_state))
{
unsigned tms_bits = tap_get_tms_path(cur_state, goal_state);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] proc jtag_init {}
On Monday 19 October 2009, michal smulski wrote:
# This line does fail
./openocd -s ../tcl/target/ -f ../tcl/target/telo.cfg -c 'interface
dummy' --debug 3 -c proc jtag_init {} {jtag arp_init-reset if { [info
exists RESET_ME] } {jtag arp_init-reset}}
Perhaps I'm unclear. How does it fail?
The jtag arp_init-reset has three extra arguments, so it
should get rejected. (Args starting if ...)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] target can't recognize?
Hi, I'm trying to download u-boot image into sdram to run, i think openocd can do it, so i wrote a script and run openocd, my dongle is j-link V7.0, cpu is FA526, and openocd version is 0.2.0, openocd-0.2.0.tar.bz2 download from http://developer.berlios.de/project/showfiles.php?group_id=4148release_id=16455 here is my script: # Daemon configuration telnet_port 23 gdb_port 2331 # JTAG interface configuration interface jlink jtag_speed 0 reset_config trst_and_srst jtag_device 4 0x1 0xf 0xe # Target configuration target fa526 little run_and_init 0 fa526 target_script 0 reset cns2132_init.script run_and_halt_time 0 1000 ##daemon_startup reset init reset_halt here is what openocd says after execute the script: Open On-Chip Debugger 0.2.0 (2009-10-09-08:05) Release $URL: http://svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.2.0/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS jtag_speed: 0 OLD SYNTAX: DEPRECATED - translating to new syntax jtag newtap CHIP TAP -irlen 4 -ircapture 0x1 -irvalue 0xf Example: STM32 has 2 taps, the cortexM3(len4) + boundaryscan(len5) jtag newtap stm32 cortexm3 ., thus creating the tap: stm32.cortexm3 jtag newtap stm32 boundary ., and the tap: stm32.boundary And then refer to the taps by the dotted name. NEW COMMAND: Runtime error, file openocd_cns2132.cfg, line 12: bad option fa526: must be one of count, create, current, names, number, or types i can't understand why such error happens, please help. Richard 2009-10-20 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] fix single step of bx instruction going into Thumb mode
On Mon, Oct 19, 2009 at 11:40 PM, David Brownell davi...@pacbell.net wrote: On Monday 19 October 2009, Nicolas Pitre wrote: Without this fix, the following code cannot be single stepped: add ip, pc, #1 bx ip [thumb code here] The same thing will be needed with ENTERX too, for ThumbEE. But we don't single step that yet. Or in fact, do much of anything with it yet. :) Thanks; I'll merge this soon. I committed this, but forgot to post back to the list that I've done so. Seems like you're much more up to speed on this than I and have spotted other cases... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] flash protection
On Tue, Oct 20, 2009 at 1:10 AM, David Brownell davi...@pacbell.net wrote: On Monday 19 October 2009, Øyvind Harboe wrote: There is an autoerase option to flash write_image. Would you object strongly to autoerase automatically unlocking the flash if necessary? That sounds more like autounlock. I'd not object to a new autounlock option, defaulting to disabled. OK. I'll see if I can get the autounlock implemented then... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Forbid build == src dir
On Tue, Oct 20, 2009 at 2:30 AM, David Brownell davi...@pacbell.net wrote: On Monday 19 October 2009, Øyvind Harboe wrote: I'd like to see openocd forbidding build == src dir: Not I. That's the *standard* build environment in almost all software projects! The first one taught to apprentice programmers. Doing anything else is unusual ... and is something which often is not supported. - it creates extra test cases. We minimally need to support build != src dir. Or we could forbid build_dir != src_dir if the number of test cases is too many ... That would be bad. I can't then use the same source to test building e.g. embedded natively hosted using the same source dir. - there can be hard to track errors such as bin2char being left in src/helper and subsequently trying to use build != src dir will fail. You mean build/src/helper or source/src/helper?? if you have a file in source/src/helper/bin2char, then a subsequent build w/build_dir != src_dir will fail. Getting rid of src as a directory name would at least help get rid of that confusion. (As if tcl isn't a kind of source code, and doc isn't source to the docs ...) No particular opinion on that. Seems like an orthogonal problem. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Forbid build == src dir
On Tue, Oct 20, 2009 at 5:11 AM, Zach Welch z...@superlucidity.net wrote: On Mon, 2009-10-19 at 19:24 +0200, Øyvind Harboe wrote: I'd like to see openocd forbidding build == src dir: Not a good idea. Why? I see that I have to give up on this one by being outvoted. That's OK. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Forbid build == src dir
Øyvind Harboe wrote: I'd like to see openocd forbidding build == src dir: Strong NAK from me. Building inside the source directory is the standard procedure for most software packages, and it makes development easier because I don't have to switch directories to examine generated files. Building out-of-tree may have some merits in special cases, but demanding it as the only way is not good. - it creates extra test cases. We minimally need to support build != src dir. - there can be hard to track errors such as bin2char being left in src/helper and subsequently trying to use build != src dir will fail. I do not see how this helps - broken dependencies in Makefiles will cause trouble either way. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] flash protection
David Brownell wrote: On Monday 19 October 2009, Øyvind Harboe wrote: Does anyone feel very strongly about flash protection? Dunno about strongly, but given my druthers it'd stay the way it is now. I've not observed it to be a problem. It is if you use Intel flashs that come up with every sector protected after every reset. IMHO, the flash protection is there to stop the application, when running normally, from accidentally erasing the flash. It's also there to help avoid boneheaded user errors. Of what kind? If I use the wrong sector number or address to erase, forcing me to unlock manually won't help - I will use the same (wrong) sector number to unlock and then repeat the erase. And to allow things like erase the whole flash to preserve the boot loader (etc) unless something explicitly enables erasing it... No. If I call for a complete chip erase, I want a complete chip erase, not something that preserves part of the flash. Either refuse the operation, or perform it as I requested. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
Dean Glazeski wrote: Another thing of interest is a feature list. I've started a feature list in this email and additions are welcome. I don't see how a GUI will improve my work in any of these areas: 1. OpenOCD server configuration a. Telnet Port b. GDB Port c. TCL Port d. Target Type e. Interface I need to write a custom board config file in most cases. A GUI won't help me set up SDRAM controller registers and other board details. 2. Start and stop OpenOCD with log output to window a. Colored output for errors, info, etc. Reduce the number of printed messages. Those remaining don't need any colouring in order to be understandable. 3. Connect to OpenOCD to issue commands a. Perhaps a list of available commands filtered based on target and interface b. Target status display c. Multiple windows for multiple targets/interfaces How would the GUI know about the target and interface configs I have written? I think xterm+telnet provide everything that is needed in this category. 4. Target flashing/loading of programs I usually add a do_flash procedure to my board scripts - a GUI can't provide much improvement here. I do think GUIs are fine for the right job - eg. for a debugger. A GUI that replaces simple commands with buttons does not provide much merit for me. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
OpenOCD has started some work on a GUI using a web interface, look at the httpd server in the development section, the builtin web server works today. It should include some memory browsing, flash programming page, simple small scale production page for non-engineers, etc. A web interface is great because OpenOCD's gui requirements are tiny and such a GUI works on *all* platforms. Duane Ellis has worked on target specific scripts to manipulate peripherals. Other than that great support for GDB, reducing noise, improving documentation and quality of target scripts would be a few things that would greatly help usability of OpenOCD. For non-builtin web server, I have a soft spot for Eclipse Java, but I'm not sure what GUI functionality I would want in Eclipse at this point, except to get CDT quirks fixed. 1. OpenOCD server configuration a. Telnet Port b. GDB Port c. TCL Port d. Target Type e. Interface I see very little win in configuring the above in a GUI. It would essentially build a command line to launch OpenOCD. Take a look at the builtin httpd server in OpenOCD. I think you'll find a lot of what you're looking for is more or less there already. On another note, this leads me to wonder if there is a possibility of an API in the future so that one could query an OpenOCD executable to see what it supports in terms of target and interface hardware. It might be possible to just make it part of the version command so that an external program can query for what devices can be used for debugging. Or it could be a command issued over the telnet or GDB connection. Thoughts? With the builtin web server, you just execute Tcl code to build web pages. That's your API effectively. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] flash protection
On Monday 19 October 2009, Michael Schwingen wrote: And to allow things like erase the whole flash to preserve the boot loader (etc) unless something explicitly enables erasing it... No. If I call for a complete chip erase, I want a complete chip erase, not something that preserves part of the flash. Either refuse the operation, or perform it as I requested. Actually, we don't *have* a formal erase the whole chip operation ... although some devices do. If we had such an operation, I'd want it to do what the hardware does. Which is in some cases exactly what I described: eraseing all unprotected data, and leaving the rest alone. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Michael Schwingen Sent: dinsdag 20 oktober 2009 8:48 To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD GUI Dean Glazeski wrote: Another thing of interest is a feature list. I've started a feature list in this email and additions are welcome. I don't see how a GUI will improve my work in any of these areas: 1. OpenOCD server configuration a. Telnet Port b. GDB Port c. TCL Port d. Target Type e. Interface I need to write a custom board config file in most cases. A GUI won't help me set up SDRAM controller registers and other board details. 2. Start and stop OpenOCD with log output to window a. Colored output for errors, info, etc. Reduce the number of printed messages. Those remaining don't need any colouring in order to be understandable. 3. Connect to OpenOCD to issue commands a. Perhaps a list of available commands filtered based on target and interface b. Target status display c. Multiple windows for multiple targets/interfaces How would the GUI know about the target and interface configs I have written? I think xterm+telnet provide everything that is needed in this category. 4. Target flashing/loading of programs I usually add a do_flash procedure to my board scripts - a GUI can't provide much improvement here. I do think GUIs are fine for the right job - eg. for a debugger. A GUI that replaces simple commands with buttons does not provide much merit for me. IMHO a GUI is a good idea but it has to be cross-platform. I have been using WxWidgets for cross platform development for several years and I must say the transfer between Windows and Linux is seemless. I don't think a GUI is usefull for debugging because OpenOCD is a man-in-the-middle. A GUI will be usefull though for testing setups and flash programming. Console commands are fine for pro's but for a beginner a GUI is much easier. Perhaps there should be a log window which shows the commands send to OpenOCD. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] fix single step of bx instruction going into Thumb mode
On Monday 19 October 2009, Øyvind Harboe wrote: Thanks; I'll merge this soon. I committed this, but forgot to post back to the list that I've done so. No prob; I saw that as I was about to merge. ;) Seems like you're much more up to speed on this than I and have spotted other cases... Came from chasing down all those Thumb2 issues! But the high order bit for that issue is that we don't yet have anything to worry about; I don't think anyone's using ThumbEE [1] enough for OpenOCD to have happened across it. That could change next year; Cortex-A8 hardware is very widely available now. - Dave [1] http://en.wikipedia.org/wiki/Jazelle#Successor:_ThumbEE ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] proc jtag_init {}
On Tue, Oct 20, 2009 at 8:24 AM, michal smulski michal.smul...@ooma.com wrote:
Here is a set of commands that reproduces my problem.
While I agree with David about -c and -f bug, this is a different one.
# Ubuntu 9.04
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
cd ./openocd
./bootstrap
./configure --enable-maintainer-mode --enable-dummy
make
cd src
# The line does not fail
./openocd -s ../tcl/target/ -f ../tcl/target/telo.cfg -c 'interface
dummy' --debug 3 -c proc jtag_init {} {jtag arp_init-reset}
# This line does fail
./openocd -s ../tcl/target/ -f ../tcl/target/telo.cfg -c 'interface
dummy' --debug 3 -c proc jtag_init {} {jtag arp_init-reset if { [info
exists RESET_ME] } {jtag arp_init-reset}}
Describe fail. It doesn't fail, it just dumps target.c:860
event 4 messages continously...
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
IMHO a GUI is a good idea but it has to be cross-platform. I have been using WxWidgets for cross platform development for several years and I must say the transfer between Windows and Linux is seemless. Cross platforms w/dependencies during compilation or running is not great either. For now the consensus(Duane and I have mostly discussed this in the past) is a built in web server for basic operations and special pages for target specific peripherals. Take the builtin httpd server for a spin. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] wsock32 MinGW-W64
2009/10/20 David Brownell davi...@pacbell.net Can you verify that all your MinGW-W64 patches have now merged, and the result builds? Compiled with MinGW-W64 on Vista 64 and MinGW-W32 as well as cygwin (with -mno-cygwin) on XP 32 and everything looks good. Many thanks. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] flash write_image unlock option
I've added an unlock option to flash write_image. Testing much appreciated! The code assumes that invoking unprotect on a sector that is already unprotected is a fast and harmless no-op which returns success. I also added a faux flash driver, the goal is to have a fake target that basic testing can easily be done against without access to any hardware. Perhaps we could interface to the gdb arm simulator target eventually? This would be an interesting case of creating a target that is not attached to any TAP... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
-Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: dinsdag 20 oktober 2009 9:33 To: Nico Coesel Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD GUI IMHO a GUI is a good idea but it has to be cross-platform. I have been using WxWidgets for cross platform development for several years and I must say the transfer between Windows and Linux is seemless. Cross platforms w/dependencies during compilation or running is not great either. The GUI doesn't need to be part of OpenOCD. For now the consensus(Duane and I have mostly discussed this in the past) is a built in web server for basic operations and special pages for target specific peripherals. Take the builtin httpd server for a spin. Does the httpd server support PHP, database access, sessions, cookies, etc, etc? Without that the functionality of a builtin webserver is extremely limited because it is very cumbersome to make active web-pages. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
Cross platforms w/dependencies during compilation or running is not great either. The GUI doesn't need to be part of OpenOCD. The alternative is to create a complete API and stick to it. We're not keen, nor do we see the need for the sort of simple functionality that has been outlined. For now the consensus(Duane and I have mostly discussed this in the past) is a built in web server for basic operations and special pages for target specific peripherals. Take the builtin httpd server for a spin. Does the httpd server support PHP, database access, sessions, cookies, etc, etc? Without that the functionality of a builtin webserver is extremely limited because it is very cumbersome to make active web-pages. It doesn't sound like you've had a look at the stuff that's already done. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] making target_write_memory() disable read-only MMU bit
Would anybody object strongly to making target_write_memory() temporarily disable MMU read-only bits? This would be e.g. to enable setting breakpoints in memory the MMU has mapped as read-only. If someone has tips or ideas on how to implement this, I would greatly appreciate input. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] making target_write_memory() disable read-only MMU bit
Øyvind Harboe wrote: Would anybody object strongly to making target_write_memory() temporarily disable MMU read-only bits? This would be e.g. to enable setting breakpoints in memory the MMU has mapped as read-only. If someone has tips or ideas on how to implement this, I would greatly appreciate input. What target ? It is simple for the Cortex A8. Ask for virt2phys address translation, then write directly to phys RAM and remember to invalidate the I-cache. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] making target_write_memory() disable read-only MMU bit
On Tue, Oct 20, 2009 at 6:10 PM, Magnus Lundin lun...@mlu.mine.nu wrote: Øyvind Harboe wrote: Would anybody object strongly to making target_write_memory() temporarily disable MMU read-only bits? This would be e.g. to enable setting breakpoints in memory the MMU has mapped as read-only. If someone has tips or ideas on how to implement this, I would greatly appreciate input. What target ? All of them eventually, but I think I'll have a look at arm9(26ejs) first... It is simple for the Cortex A8. Ask for virt2phys address translation, then write directly to phys RAM and remember to invalidate the I-cache. We are agreed that we want this then? Patches gladly accepted anyone! ;-) -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
On Tuesday 20 October 2009, Øyvind Harboe wrote: The alternative is to create a complete API and stick to it. We're not keen, nor do we see the need for the sort of simple functionality that has been outlined. Web access *IS* an API ... at least, as soon as any client starts to use it that way. That's why there's been such a lot of interest in web programming interfaces that uplevel things from screen scraping to something that's more maintainable. IMO that's kind of moot until whatever non-commandline UI starts to get more users, though. :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
I would like to see openocd always start, even if the config file is invalid. Then, it can be configured via telnet and, hopefully, Have a command to dump a config file. If the telnet interface supported completion a la Cisco routers (press ? to list available completions), it would not be difficult to write flexible GUIs that wrap around it, and it would be nicer to use in and of itself. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: Tuesday, October 20, 2009 11:19 AM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD GUI On Tuesday 20 October 2009, Øyvind Harboe wrote: The alternative is to create a complete API and stick to it. We're not keen, nor do we see the need for the sort of simple functionality that has been outlined. Web access *IS* an API ... at least, as soon as any client starts to use it that way. That's why there's been such a lot of interest in web programming interfaces that uplevel things from screen scraping to something that's more maintainable. IMO that's kind of moot until whatever non-commandline UI starts to get more users, though. :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch/rft] XSVF: call svf_add_statemove() as needed
This layers parts of XSVF directly over SVF, to handle XSTATE better,
instead of expecting jtag_add_pathmove() to conform (it doesn't).
It also removes related bogus comments about jtag_add_pathmove().
There is one set of XSTATE cases that's not handled right yet: when
it's used to build some arbitrary path, not moving between two stable
states. The path isn't collected yet, but -- new! -- that error case
will now trigger a specific warning.
Handling of state transition paths is, overall, still a mess. I think
they should all be specified as paths not unlike SVF uses, and then
compiled to the bitstrings ... so that we can actually make sense of
the paths. (See the extra clocks, detours through RUN, etc.)
---
I can't see this causing any regressions, but it should make
XSVF conform better to the spec in at least three ways: handling
of RESET, skipping NOP transitions, and doing what SVF specifies
(instead of what the new default paths do) where relevant.
Run on top of current git, to get some RESET handling fixes.
src/jtag/jtag.h | 24 -
src/svf/svf.c| 18 +---
src/svf/svf.h| 21 +++
src/xsvf/Makefile.am |1
src/xsvf/xsvf.c | 54 -
5 files changed, 65 insertions(+), 53 deletions(-)
--- a/src/jtag/jtag.h
+++ b/src/jtag/jtag.h
@@ -538,29 +538,7 @@ extern void jtag_add_pathmove(int num_st
* @return ERROR_OK on success, or an error code on failure.
*
* Moves from the current state to the goal \a state.
- *
- * This needs to be handled according to the xsvf spec, see the XSTATE
- * command description. From the XSVF spec, pertaining to XSTATE:
- *
- * For special states known as stable states (Test-Logic-Reset,
- * Run-Test/Idle, Pause-DR, Pause- IR), an XSVF interpreter follows
- * predefined TAP state paths when the starting state is a stable state
- * and when the XSTATE specifies a new stable state. See the STATE
- * command in the [Ref 5] for the TAP state paths between stable
- * states.
- *
- * For non-stable states, XSTATE should specify a state that is only one
- * TAP state transition distance from the current TAP state to avoid
- * undefined TAP state paths. A sequence of multiple XSTATE commands can
- * be issued to transition the TAP through a specific state path.
- *
- * @note Unless @c tms_bits holds a path that agrees with [Ref 5] in the
- * above spec, then this code is not fully conformant to the xsvf spec.
- * This puts a burden on tap_get_tms_path() function from the xsvf spec.
- * If in doubt, you should confirm that that burden is being met.
- *
- * Otherwise, @a goal_state must be immediately reachable in one clock
- * cycle, and does not need to be a stable state.
+ * Both states must be stable.
*/
extern int jtag_add_statemove(tap_state_t goal_state);
--- a/src/svf/svf.c
+++ b/src/svf/svf.c
@@ -31,8 +31,8 @@
#include config.h
#endif
-#include svf.h
#include jtag.h
+#include svf.h
#include time_support.h
@@ -311,7 +311,7 @@ static const char* tap_state_svf_name(ta
return ret;
}
-static int svf_add_statemove(tap_state_t state_to)
+int svf_add_statemove(tap_state_t state_to)
{
tap_state_t state_from = cmd_queue_cur_state;
uint8_t index;
@@ -619,9 +619,10 @@ static int svf_parse_cmd_string(char *st
return ERROR_OK;
}
-static int svf_tap_state_is_stable(tap_state_t state)
+bool svf_tap_state_is_stable(tap_state_t state)
{
- return ((TAP_RESET == state) || (TAP_IDLE == state) || (TAP_DRPAUSE ==
state) || (TAP_IRPAUSE == state));
+ return (TAP_RESET == state) || (TAP_IDLE == state)
+ || (TAP_DRPAUSE == state) || (TAP_IRPAUSE == state);
}
static int svf_tap_state_is_valid(tap_state_t state)
@@ -1082,6 +1083,7 @@ static int svf_run_command(struct comman
field.num_bits = i;
field.out_value = svf_tdi_buffer[svf_buffer_index];
field.in_value = svf_tdi_buffer[svf_buffer_index];
+ /* NOTE: doesn't use SVF-specified state paths */
jtag_add_plain_dr_scan(1, field,
svf_para.dr_end_state);
svf_buffer_index += (i + 7) 3;
@@ -1177,6 +1179,7 @@ static int svf_run_command(struct comman
field.num_bits = i;
field.out_value = svf_tdi_buffer[svf_buffer_index];
field.in_value = svf_tdi_buffer[svf_buffer_index];
+ /* NOTE: doesn't use SVF-specified state paths */
jtag_add_plain_ir_scan(1, field,
svf_para.ir_end_state);
svf_buffer_index += (i + 7) 3;
@@ -1337,8 +1340,10 @@ static int svf_run_command(struct comman
free(path);
return ERROR_FAIL;
}
+
Re: [Openocd-development] What's git's equivalent to svn version #?
You can do that if you want. Otherwise, since every git command uses git rev-parse implicitly, the result of git describe is a valid revision descriptor. You can git checkout -b my_temp_branch output_of_git_describe -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: Saturday, October 17, 2009 3:50 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] What's git's equivalent to svn version #? On Saturday 17 October 2009, Øyvind Harboe wrote: How do I figure out what version a git describe refers to? git rev-parse $(git describe) ___ 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] cast from long to HANDLER on MinGW-W64
“What do you think is the worst that could happen by issuing a 0 + on an integer value that is meant to be used as a valid pointer in the first place?” Remember: (((int32_t *)0) + 5) == 20. From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Redirect Slash NIL Sent: Saturday, October 17, 2009 6:14 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64 2009/10/17 David Brownell davi...@pacbell.netmailto:davi...@pacbell.net What's with the strange (HANDLE)(0 + _get_osfhandle())? The 0 + is mutant... Yeah. The problem here is that HANDLE is typedef'd as void* (in winnt.h), whereas _get_osfhandle() returns a long (http://msdn.microsoft.com/en-us/library/ks2530z6.aspx), and gcc insists on returning a warning when casting a 32 bit long into a 64 bit pointer (cast to pointer from integer of different size). The most elegant way I found to avoid that warning is to do an arithmetic operation first. Of course one has to wonder why a function that is meant to return a handle does not actually return a type HANDLE... The only other way I see to do it is to add idefs for MINGW64 so that we cast _get_osfhandle() to a long long first. What do you think is the worst that could happen by issuing a 0 + on an integer value that is meant to be used as a valid pointer in the first place? _get_osfhandle is meant to provide a pointer (handle) that is valid for the OS it's actually being executed in. It's just that for whatever reason, the makers of that function decided to return anything but a handle but I still think what we're doing here should be pretty safe. Regards ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RFC -- git repo cleanup/rebase
As noted recently by Alex, we're carrying around significant quantities of unwanted cruft in the git repository. If you have a current clone, you can see it by: git whatchanged -- zy1000 That's around 100 MBytes of useless stuff that gets pulled, and then carried around in repositories. We want to get rid of that before 0.3.x releases go out. (Also a few other noise commits.) This is a one-time fix, addressing some SVN conversion issues; such changes should not happen again. Since we only recently switched over to use git, we don't expect many folk to have significant branches yet; such branches would be disturbed by this switchover. So here's my rough plan on how to fix: - At time T, I rename the openocd repository to openocd-old. You'll be able to tell T since git pull (or clone) using the previous git:// URL won't work. The openocd-old repo will be a temporary backup, which we expect will vanish by the end of November. It may help if you need to rebase some branch. - At time T+1, I provide a new openocd repository which is equivalent to openocd-old ... but is rebased to purge those useless commits, and their data. Commit IDs before about a year ago will be unchanged. All newer ones will be different, because they won't have have those useless commits in their ancestry. (I'll use the grafts file I previously posted.) - From time T+2 and later, everyone will want to get new clones of that repository. I'll send out an email announcing this, presumably as a followup on this thread. And I'm proposing that time T be about 11pm PST (a bit over twelve hours from when I write this). Committers, please plan to be idle for a few hours on either side of that, just to make this conversion easier on me. :) Comments? I've not done one of these transitions before, so I'm not quite clear on what could trip anyone up if they don't re-clone. But I know that re-cloning is safe, and will be a lot cheaper than the original bloated clones were. :) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ESC Boston report
On Thu, Oct 15, 2009 at 12:39 AM, David Brownell davi...@pacbell.netwrote: On Monday 28 September 2009, Brian Hutchinson wrote: I have a BeagleBoard now :) It was a good but busy week! Thanks for the report. ESC can be fun. TI didn't happen to have XDS100 v2 prototypes did they? http://wiki.davincidsp.com/index.php/XDS100 It's an oversight that OpenOCD doesn't support this yet; it's basically Yet Another FT2232-based adapter, geared towards TI boards (like Beagle). The v2 uses the highspeed parts and supports adaptive clocking. It's not shiping yet though. I'd think that when XDS100 v2 ships, it ought to be fairly popular for use with Beagle and such. ;) - Dave Looks like they had something similar there: http://www.embedded.com/esc/22864?printable=true ... but I didn't attend. So many things going on at the same time you kind of miss a lot. Regards, Brian ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC -- git repo cleanup/rebase
Thanks for spotting this and doing the work! It's great to have this out of the way and your timing is good. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ESC Boston report
On Tuesday 20 October 2009, Brian Hutchinson wrote: Looks like they had something similar there: http://www.embedded.com/esc/22864?printable=true Not quite the same thing ... that's a DSP-on-a-stick, with an on-board XDS100-compatible JTAG. That is, it uses a full speed FT2232, not high speed. If someone were to teach OpenOCD how to support that C55x+ DSP as a debug target, much the same code would also be able to talk to the C55x DSPs on OMAP1 and OMAP2 parts... 38-bit Instruction Registers and all. While a $55 DSP platform is intriguing, I somehow do not think that GCC is going to get good support for code generation there any time soon. ;) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
A very valid point indeed. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC -- git repo cleanup/rebase
On Tue, 2009-10-20 at 11:03 -0700, David Brownell wrote: As noted recently by Alex, we're carrying around significant quantities of unwanted cruft in the git repository. If you have a current clone, you can see it by: git whatchanged -- zy1000 That's around 100 MBytes of useless stuff that gets pulled, and then carried around in repositories. We want to get rid of that before 0.3.x releases go out. (Also a few other noise commits.) This is a one-time fix, addressing some SVN conversion issues; such changes should not happen again. Since we only recently switched over to use git, we don't expect many folk to have significant branches yet; such branches would be disturbed by this switchover. So here's my rough plan on how to fix: - At time T, I rename the openocd repository to openocd-old. You'll be able to tell T since git pull (or clone) using the previous git:// URL won't work. The openocd-old repo will be a temporary backup, which we expect will vanish by the end of November. It may help if you need to rebase some branch. - At time T+1, I provide a new openocd repository which is equivalent to openocd-old ... but is rebased to purge those useless commits, and their data. Commit IDs before about a year ago will be unchanged. All newer ones will be different, because they won't have have those useless commits in their ancestry. (I'll use the grafts file I previously posted.) - From time T+2 and later, everyone will want to get new clones of that repository. I'll send out an email announcing this, presumably as a followup on this thread. And I'm proposing that time T be about 11pm PST (a bit over twelve hours from when I write this). Committers, please plan to be idle for a few hours on either side of that, just to make this conversion easier on me. :) Comments? Looks great to me. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rft] XSVF: call svf_add_statemove() as needed
On Tuesday 20 October 2009, David Brownell wrote: This layers parts of XSVF directly over SVF, to handle XSTATE better, instead of expecting jtag_add_pathmove() to conform (it doesn't). It also removes related bogus comments about jtag_add_pathmove(). ... and in fact I'm thinking that XSVF should never use jtag_add_statemove() in any situation; it should only use the now-public svf_add_statemove(). The only places it doesn't look obviously safe to do that switch is in the code handling output of the OpenOCD-specific svf2xsvf.py script, which adds some opcodes of its own invention. If I trace those back to their genesis (in SVF or Lattice's SVF extensions), I think it's correct there too... though I don't seem to find docs on the Lattice extensions. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC -- git repo cleanup/rebase
On Tuesday 20 October 2009, Zach Welch wrote: - From time T+2 and later, everyone will want to get new clones of that repository. I'll send out an email announcing this, presumably as a followup on this thread. Actually, it turns out that I may be able to avoid that step ... leave the old stuff in the repository, from which it will get garbage collected in a few weeks. There would be an advantage for anyone who has a private branch; it'll be easier to bring it up to date. The disadvantage will be that until that GC happens, HTTP clones will still need to incur the costs of larger-than-desirable fetches. I'm not sure yet if I'll go that route. It'd be easier on current clients, if I understand things right, which is why I sort of like that notion: just git pull, no need to make new clones. And I'm proposing that time T be about 11pm PST (a bit over twelve hours from when I write this). Committers, please plan to be idle for a few hours on either side of that, just to make this conversion easier on me. :) Comments? Looks great to me. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC -- git repo cleanup/rebase
On Tue, 2009-10-20 at 14:49 -0700, David Brownell wrote: On Tuesday 20 October 2009, Zach Welch wrote: - From time T+2 and later, everyone will want to get new clones of that repository. I'll send out an email announcing this, presumably as a followup on this thread. Actually, it turns out that I may be able to avoid that step ... leave the old stuff in the repository, from which it will get garbage collected in a few weeks. There would be an advantage for anyone who has a private branch; it'll be easier to bring it up to date. The disadvantage will be that until that GC happens, HTTP clones will still need to incur the costs of larger-than-desirable fetches. I'm not sure yet if I'll go that route. It'd be easier on current clients, if I understand things right, which is why I sort of like that notion: just git pull, no need to make new clones. I agree that this might be a better migration path, since it provides better continuity of service. I had been thinking about pulling the new repository into the old to rebase my branches, so I had started to postulate a similar strategy might be feasible. If we go this route, would we even need to expose an '-old' GIT tree? All of its content still exists in the original Subversion repository; we lose nothing by dropping it and gain nothing by keeping it, right? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD J-link under Windows
On Tue, Oct 20, 2009 at 9:47 PM, wxzzzh wxz...@163.com wrote: From web search, I know you are a specialist on openocd and j-link, i have problem in my debug with them, it always Error: Cannot find jlink Interface!. I guess it's because of the lack of proper driver installation, but i can't find a right one. Would you please do me a favor to send me one or it's link? Hmm, I am not an expert. Anyway, this means that you need to install libusb-win32 driver. Personally I use the libusb-win32 device driver because the filter driver can cause major problems for people (especially Vista). You can use the INF wizard to generate the INF file and then use the device manager to update the driver from the original driver from Segger to libusb-win32. Your other program like IAR will no longer work with J-Link, that is the downside of device driver mode. -- 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] RFC -- git repo cleanup/rebase
On Tuesday 20 October 2009, Zach Welch wrote: On Tue, 2009-10-20 at 14:49 -0700, David Brownell wrote: On Tuesday 20 October 2009, Zach Welch wrote: - From time T+2 and later, everyone will want to get new clones of that repository. I'll send out an email announcing this, presumably as a followup on this thread. Actually, it turns out that I may be able to avoid that step ... leave the old stuff in the repository, from which it will get garbage collected in a few weeks. There would be an advantage for anyone who has a private branch; it'll be easier to bring it up to date. The disadvantage will be that until that GC happens, HTTP clones will still need to incur the costs of larger-than-desirable fetches. I'm not sure yet if I'll go that route. It'd be easier on current clients, if I understand things right, which is why I sort of like that notion: just git pull, no need to make new clones. I agree that this might be a better migration path, since it provides better continuity of service. I had been thinking about pulling the new repository into the old to rebase my branches, so I had started to postulate a similar strategy might be feasible. If we go this route, would we even need to expose an '-old' GIT tree? In one word: backup! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC -- git repo cleanup/rebase
On Tue, 2009-10-20 at 16:24 -0700, David Brownell wrote: On Tuesday 20 October 2009, Zach Welch wrote: On Tue, 2009-10-20 at 14:49 -0700, David Brownell wrote: On Tuesday 20 October 2009, Zach Welch wrote: - From time T+2 and later, everyone will want to get new clones of that repository. I'll send out an email announcing this, presumably as a followup on this thread. Actually, it turns out that I may be able to avoid that step ... leave the old stuff in the repository, from which it will get garbage collected in a few weeks. There would be an advantage for anyone who has a private branch; it'll be easier to bring it up to date. The disadvantage will be that until that GC happens, HTTP clones will still need to incur the costs of larger-than-desirable fetches. I'm not sure yet if I'll go that route. It'd be easier on current clients, if I understand things right, which is why I sort of like that notion: just git pull, no need to make new clones. I agree that this might be a better migration path, since it provides better continuity of service. I had been thinking about pulling the new repository into the old to rebase my branches, so I had started to postulate a similar strategy might be feasible. If we go this route, would we even need to expose an '-old' GIT tree? In one word: backup! I was careful in the use of the word expose. :) Yes, we definitely want to create a copy on the server for backup purposes, but does it need to be published for distribution? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Forbid build == src dir
Le 20/10/2009 02:59, Øyvind Harboe a écrit : On Tue, Oct 20, 2009 at 5:11 AM, Zach Welchz...@superlucidity.net wrote: On Mon, 2009-10-19 at 19:24 +0200, Øyvind Harboe wrote: I'd like to see openocd forbidding build == src dir: Not a good idea. Why? Because it is ridiculous. I see that I have to give up on this one by being outvoted. That's OK. -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD J-link under Windows
On Wed, Oct 21, 2009 at 8:12 AM, wxzzzh wxz...@163.com wrote: for the device driver, it's said you can never uninstall it once you install it, does this mean i'll lost the chance to use Segger softwares forever? You can switch between the Segger driver and libusb-win32 device driver. When you need to use IAR or similar programs which need Segger driver, you use Device Manager to update libusb-win32 device driver to the Segger driver. When you need to use OpenOCD, you can switch to libusb-win32 device driver. The filter driver is better in this aspect. You do not need to switch driver. But it may cause you to lose all your USB device or BSOD, especially under Windows Vista as per reports. how about install such driver in Fedora under Vmware? is it workable? I do not use Vmware since I use Vista along with Ubuntu 9.04 dual boot. It might work with Vmware. But why do you want to do that? OpenOCD works under Linux. Version 0.2 makes J-Link work fine as other supported JTag debuggers. -- 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/rft] XSVF: call svf_add_statemove() as needed
On Tuesday 20 October 2009, David Brownell wrote: This layers parts of XSVF directly over SVF, to handle XSTATE better, instead of expecting jtag_add_pathmove() to conform (it doesn't). I'm going to commit this even though I can't test it. Since we *know* jtag_add_statemove() [TYPO ABOVE!] is wrong, using svf_add_statemove() has got to be at least somewhat better. If it's not ... we'll have a handle on a bug affecting both SVF and XSVF. I also tweaked the User's Guide to mention the two XSVF utility scripts, and the five XSVF extension opcodes that OpenOCD supports. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC -- git repo cleanup/rebase
On Tuesday 20 October 2009, Zach Welch wrote: If we go this route, would we even need to expose an '-old' GIT tree? In one word: backup! I was careful in the use of the word expose. :) Yes, we definitely want to create a copy on the server for backup purposes, but does it need to be published for distribution? The way things are set up, I'm not sure where to store it that would *NOT* be publicly visible ... is that a big deal? It's going to be a temporary thing in any case. Different issue ... the 0.2.0 tag has already been made, so after re-basing, we can't really change what that means. How about ... just calling it 0.2 (and then 0.3 etc)? If we ever need put out a bugfix we can go from Major.Minor to Major.Minor.DOT easily enough, but meanwhile that extra zero seems to add no real value. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FYI - current JTAG state-state path tables
This is the hack I used to dump TMS path tables at startup.
---
src/jtag/interface.c | 41 +
1 file changed, 41 insertions(+)
--- a/src/jtag/interface.c
+++ b/src/jtag/interface.c
@@ -375,6 +375,47 @@ tap_state_t tap_state_by_name(const char
return TAP_INVALID;
}
+static void dump_tap_seq(tap_state_t cur, tap_state_t end)
+{
+ unsigned path = tap_get_tms_path(cur, end);
+ unsigned len = tap_get_tms_path_len(cur, end);
+
+ printf(\t{ %s, tap_state_name(cur));
+ while (len--) {
+ cur = tap_state_transition(cur, (path 1) == 1);
+ path = 1;
+ printf(, %s, tap_state_name(cur));
+ }
+ printf( }\n);
+}
+
+static void dump_tap_table(const char *label, tms_table *table)
+{
+ static const tap_state_t stable[6] = {
+ TAP_RESET, TAP_IDLE,
+ TAP_DRSHIFT, TAP_DRPAUSE,
+ TAP_IRSHIFT, TAP_IRPAUSE,
+ };
+
+ tms_seqs = table;
+ printf(TMS Table: %s\n, label);
+
+ for (int i = 0; i 6; i++) {
+ printf(\t/* from %s */\n, tap_state_name(stable[i]));
+ for (int j = 0; j 6; j++)
+ dump_tap_seq(stable[i], stable[j]);
+ }
+ printf(\n);
+}
+
+static void dump_tap_tables(void) __attribute__ ((constructor));
+static void dump_tap_tables(void)
+{
+ dump_tap_table(old, old_tms_seqs);
+ dump_tap_table(short, short_tms_seqs);
+ fflush(stdout);
+}
+
#ifdef _DEBUG_JTAG_IO_
#define JTAG_DEBUG_STATE_APPEND(buf, len, bit) \
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FYI - current JTAG state-state path tables
Since I was trying to make sense of them, I wrote a quickie
utility to dump the old and short path tables on startup.
The results follow (and the patch will be in the next email).
Format: { start, [next, ...,] end }. Yes, they all involve
at least one TCK cycle, even if start == end.
I'm thinking that after the next release is out, we should
change how we work with those paths ... always init them from
readable lists of states, somewhat resembling these, so we can
easily see what transitions the various JTAG adapters are being
told to use. But that sort of stuff is for later.
Notice how even the new short paths are in most cases longer
than they need to be...
- Dave
TMS Table: old
/* from RESET */
{ RESET, RESET, RESET, RESET, RESET, RESET, RESET, RESET }
{ RESET, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE,
RUN/IDLE }
{ RESET, RESET, RESET, RESET, RUN/IDLE, DRSELECT, DRCAPTURE, DRSHIFT }
{ RESET, RUN/IDLE, DRSELECT, DRCAPTURE, DREXIT1, DRPAUSE, DRPAUSE,
DRPAUSE }
{ RESET, RESET, RESET, RUN/IDLE, DRSELECT, IRSELECT, IRCAPTURE, IRSHIFT
}
{ RESET, RUN/IDLE, DRSELECT, IRSELECT, IRCAPTURE, IREXIT1, IRPAUSE,
IRPAUSE }
/* from RUN/IDLE */
{ RUN/IDLE, DRSELECT, IRSELECT, RESET, RESET, RESET, RESET, RESET }
{ RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE,
RUN/IDLE }
{ RUN/IDLE, DRSELECT, DRCAPTURE, DREXIT1, DRPAUSE, DRPAUSE, DREXIT2,
DRSHIFT }
{ RUN/IDLE, DRSELECT, DRCAPTURE, DREXIT1, DRPAUSE, DRPAUSE, DRPAUSE,
DRPAUSE }
{ RUN/IDLE, DRSELECT, IRSELECT, IRCAPTURE, IREXIT1, IRPAUSE, IREXIT2,
IRSHIFT }
{ RUN/IDLE, DRSELECT, IRSELECT, IRCAPTURE, IREXIT1, IRPAUSE, IRPAUSE,
IRPAUSE }
/* from DRSHIFT */
{ DRSHIFT, DREXIT1, DRUPDATE, DRSELECT, IRSELECT, RESET, RESET, RESET }
{ DRSHIFT, DREXIT1, DRPAUSE, DRPAUSE, DRPAUSE, DREXIT2, DRUPDATE,
RUN/IDLE }
{ DRSHIFT, DRSHIFT, DRSHIFT, DRSHIFT, DRSHIFT, DRSHIFT, DRSHIFT,
DRSHIFT }
{ DRSHIFT, DREXIT1, DRPAUSE, DRPAUSE, DRPAUSE, DRPAUSE, DRPAUSE,
DRPAUSE }
{ DRSHIFT, DREXIT1, DRUPDATE, DRSELECT, IRSELECT, IRCAPTURE, IRSHIFT,
IRSHIFT }
{ DRSHIFT, DREXIT1, DRUPDATE, DRSELECT, IRSELECT, IRCAPTURE, IREXIT1,
IRPAUSE }
/* from DRPAUSE */
{ DRPAUSE, DREXIT2, DRUPDATE, DRSELECT, IRSELECT, RESET, RESET, RESET }
{ DRPAUSE, DRPAUSE, DRPAUSE, DRPAUSE, DRPAUSE, DREXIT2, DRUPDATE,
RUN/IDLE }
{ DRPAUSE, DRPAUSE, DRPAUSE, DRPAUSE, DRPAUSE, DRPAUSE, DREXIT2,
DRSHIFT }
{ DRPAUSE, DREXIT2, DRUPDATE, DRSELECT, DRCAPTURE, DREXIT1, DRPAUSE,
DRPAUSE }
{ DRPAUSE, DRPAUSE, DREXIT2, DRUPDATE, DRSELECT, IRSELECT, IRCAPTURE,
IRSHIFT }
{ DRPAUSE, DREXIT2, DRUPDATE, DRSELECT, IRSELECT, IRCAPTURE, IREXIT1,
IRPAUSE }
/* from IRSHIFT */
{ IRSHIFT, IREXIT1, IRUPDATE, DRSELECT, IRSELECT, RESET, RESET, RESET }
{ IRSHIFT, IREXIT1, IRPAUSE, IRPAUSE, IRPAUSE, IREXIT2, IRUPDATE,
RUN/IDLE }
{ IRSHIFT, IREXIT1, IRUPDATE, DRSELECT, DRCAPTURE, DRSHIFT, DRSHIFT,
DRSHIFT }
{ IRSHIFT, IREXIT1, IRUPDATE, DRSELECT, DRCAPTURE, DREXIT1, DRPAUSE,
DRPAUSE }
{ IRSHIFT, IRSHIFT, IRSHIFT, IRSHIFT, IRSHIFT, IRSHIFT, IRSHIFT,
IRSHIFT }
{ IRSHIFT, IREXIT1, IRPAUSE, IRPAUSE, IRPAUSE, IRPAUSE, IRPAUSE,
IRPAUSE }
/* from IRPAUSE */
{ IRPAUSE, IREXIT2, IRUPDATE, DRSELECT, IRSELECT, RESET, RESET, RESET }
{ IRPAUSE, IRPAUSE, IRPAUSE, IRPAUSE, IRPAUSE, IREXIT2, IRUPDATE,
RUN/IDLE }
{ IRPAUSE, IRPAUSE, IRPAUSE, IREXIT2, IRUPDATE, DRSELECT, DRCAPTURE,
DRSHIFT }
{ IRPAUSE, IREXIT2, IRUPDATE, DRSELECT, DRCAPTURE, DREXIT1, DRPAUSE,
DRPAUSE }
{ IRPAUSE, IRPAUSE, IREXIT2, IRUPDATE, DRSELECT, IRSELECT, IRCAPTURE,
IRSHIFT }
{ IRPAUSE, IREXIT2, IRUPDATE, DRSELECT, IRSELECT, IRCAPTURE, IREXIT1,
IRPAUSE }
TMS Table: short
/* from RESET */
{ RESET, RESET, RESET, RESET, RESET, RESET, RESET, RESET }
{ RESET, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE,
RUN/IDLE }
{ RESET, RESET, RESET, RESET, RUN/IDLE, DRSELECT, DRCAPTURE, DRSHIFT }
{ RESET, RUN/IDLE, DRSELECT, DRCAPTURE, DREXIT1, DRPAUSE, DRPAUSE,
DRPAUSE }
{ RESET, RESET, RESET, RUN/IDLE, DRSELECT, IRSELECT, IRCAPTURE, IRSHIFT
}
{ RESET, RUN/IDLE, DRSELECT, IRSELECT, IRCAPTURE, IREXIT1, IRPAUSE,
IRPAUSE }
/* from RUN/IDLE */
{ RUN/IDLE, DRSELECT, IRSELECT, RESET, RESET, RESET, RESET, RESET }
{ RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE, RUN/IDLE,
RUN/IDLE }
{ RUN/IDLE, DRSELECT, DRCAPTURE, DRSHIFT }
{ RUN/IDLE, DRSELECT, DRCAPTURE, DREXIT1, DRPAUSE }
{ RUN/IDLE, DRSELECT, IRSELECT, IRCAPTURE, IRSHIFT }
{ RUN/IDLE, DRSELECT, IRSELECT, IRCAPTURE, IREXIT1, IRPAUSE }
/* from DRSHIFT */
{ DRSHIFT, DREXIT1, DRUPDATE, DRSELECT, IRSELECT, RESET,
Re: [Openocd-development] OpenOCD J-link under Windows
On Wed, Oct 21, 2009 at 11:08 AM, wxzzzh wxz...@163.com wrote: with vmware, you can run gdb in linux, openocd in windows, and let them together, you need not to boot to change os you want to use, it's really convenient, recommend you to take a try. As I mentioned, you can run openocd under Linux. And often VMWare (or other VM software in this aspect) is problematic with USB as far as I know. Personally I do not use VMware or other virtual machine software. i am encounting a new problem, my cpu can't halt when gdb tried to connect with openocd, here is what openocd says: Error: invalid mode value encountered 0 Error: cpsr contains invalid mode value - communication failure how this happens? i can halt the cpu using jlink commander, but can't using openocd. my cpu is cns2132, which have a fa526 core, i can't access it's cp15 registers using jlink commander, and i found openocd support fa526 core now, that's why i am trying to us it to debug. Please use the mailing list. Thanks. I do not know abotu fa256 core. Hopefully others can help you. -- 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] RFC -- git repo cleanup/rebase
On Tue, 2009-10-20 at 20:31 -0700, David Brownell wrote: On Tuesday 20 October 2009, Zach Welch wrote: If we go this route, would we even need to expose an '-old' GIT tree? In one word: backup! I was careful in the use of the word expose. :) Yes, we definitely want to create a copy on the server for backup purposes, but does it need to be published for distribution? The way things are set up, I'm not sure where to store it that would *NOT* be publicly visible ... is that a big deal? It's going to be a temporary thing in any case. Fair enough. I just want to minimize vestigial artifacts. :) Different issue ... the 0.2.0 tag has already been made, so after re-basing, we can't really change what that means. From the discussion on this page about retagging, http://www.kernel.org/pub/software/scm/git/docs/git-tag.html How about ... just calling it 0.2 (and then 0.3 etc)? ... this would be option #1. Arguably, the sane thing to do. :) Since the $SUBJECT shows that we remain in transition between SVN and GIT, we could probably take option #2 too. It even provides a template for the e-mail that details the actions users can take to remove the old 0.2.0 tag. We're more-or-less at a flag day anyway, right? If we ever need put out a bugfix we can go from Major.Minor to Major.Minor.DOT easily enough, but meanwhile that extra zero seems to add no real value. I see the .0 much like a $.99 price tag. The least-significant digits have subtle psychological influence on consumers. I think they help denote the amount of change since the last version more clearly. Also, the three-digit standard is easier to handle in the release scripts, so your suggestion adds more logic for me to get wrong. ;) What about openocd-x.y.z? With GIT, that allows cleanly distinct tag clouds in forked copies (e.g. freeocd-*, gnuocd-*, etc.). :) While we could use 'x.y.z' ourselves, the two forms of tags again make automation slightly more challenging Too forward thinking? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Forbid build == src dir
On Tue, 2009-10-20 at 08:58 +0200, Øyvind Harboe wrote:
On Tue, Oct 20, 2009 at 2:30 AM, David Brownell davi...@pacbell.net wrote:
On Monday 19 October 2009, Øyvind Harboe wrote:
[snip]
- there can be hard to track errors such as bin2char being
left in src/helper and subsequently trying to use build !=
src dir will fail.
You mean build/src/helper or source/src/helper??
if you have a file in source/src/helper/bin2char, then
a subsequent build w/build_dir != src_dir will fail.
Does this patch fix this particular problem for you?
I expect the best solution is always run 'make distclean' before
switching away from src_dir == build_dir.
--Z
diff --git a/src/helper/Makefile.am b/src/helper/Makefile.am
index 67250a1..b12d400 100644
--- a/src/helper/Makefile.am
+++ b/src/helper/Makefile.am
@@ -48,22 +48,24 @@ noinst_HEADERS = \
fileio.h \
jim.h \
jim-eventloop.h \
- system.h \
+ system.h
+
+EXTRA_DIST = \
startup.tcl \
bin2char.c
-BIN2C = bin2char$(EXEEXT_FOR_BUILD)
+BIN2C = $(builddir)/bin2char$(EXEEXT_FOR_BUILD)
BUILT_SOURCES = $(BIN2C)
-$(BIN2C): bin2char.c
- ${CC_FOR_BUILD} ${CFLAGS_FOR_BUILD} $(srcdir)/bin2char.c -o $@
+$(BIN2C): $(srcdir)/bin2char.c
+ $(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) -o $@ $
# Convert .tcl to cfile
-startup_tcl.c: startup.tcl $(BIN2C)
- ./$(BIN2C) startup_tcl $(srcdir)/startup.tcl $@
+startup_tcl.c: $(srcdir)/startup.tcl $(BIN2C)
+ $(BIN2C) startup_tcl $(srcdir)/startup.tcl $@
# add startup_tcl.c to make clean list
-CLEANFILES = startup_tcl.c bin2char$(EXEEXT_FOR_BUILD)
+CLEANFILES = startup_tcl.c $(BIN2C)
MAINTAINERCLEANFILES = $(srcdir)/Makefile.in
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
