Re: [Openocd-development] OpenOCD + beagle
Magnus Lundin wrote: Hi list, I know there is a lot of fixing to get a stable 0.2.0 so this is clearly for next release. But I also know that some folks wants to get going with CortexA8, so here it comes. Great! Many thanks! Dave, Sergey: This does look like a really *good* starting point for the last step to final OMAP3 support in OpenOCD, no? Again many thanks and best regards Dirk Index: src/target/Makefile.am Index: src/target/armv7a.c Index: src/target/armv7a.h Index: src/target/cortex_a8.c Index: src/target/cortex_a8.h Index: src/target/armv7m.c Index: src/target/arm_adi_v5.c Index: src/target/arm_adi_v5.h This code has mainly been developed and tested against R1606, it has been built and tested against R2294 where it runs but step and resume commands are broken due to regression in codebase, this should be fixed in current head. I do have not have access to the ARMv7A/R archtecture manual so it is hard to make a precise distinction between CorexA8 and ARMv7A features. The ARMv7A architecture and register set is a variant of the armv4/5/6 and it is not a variant of the ARMv7M used by CortexM3. The debug interface is ARM_ADI_V5, most (hopefully all) changes to handle the differences from the CortexM3 implementation has already been added to arm_adi_v5.c. This code is really written for OMAP3530. The identification of debug resources from the ROM table is not implemented, there is code to scan a rom table in arm_adi_v5.c:dap_info_command but it is not used for setting adresses of debug resources. In the most general situation every memory mapped debug resource, including ROM and RAM, must be associated with a dap number and a memap address, this can, and probably most often will, be equal to the processor memory bus address but this is not necessary. The OMAP3530 uses two memap access ports, dap 0 and dap 1. dap ap #0 is connected to L3 interconnect, with passthrough to L4 Emu dap ap #1 is connected to L4 Emu interconnect , with access to L4 Wakeup and holds the ROM table This means that most memory bus accesses should be done through dap ap #0, but access to L4 Emu interconnect and scanning the ROM table should be done through dap ap #1. The are at present some defines to handle this in cortex_a8.c, they should be replaced with more general code, but that should probably be done when we have access to other Cortexa8 implementations. #define swjdp_memoryap 0 #define swjdp_debugap 1 #define OMAP3530_DEBUG_BASE 0x54011000 -- PATCH AGAINST 2294 arm_adi_v7m_R2294.patch Index: src/target/arm_adi_v5.c Index: src/target/arm_adi_v5.h Index: src/target/armv7m.c The changes in these files move the dap command handler implementations to arm_adi_v5.c, leaving just thin wrappers in armv7m.c. There should be no change in functionality here. Should be harmless to commit. -- NEW FILES Index: src/target/armv7a.c Index: src/target/armv7a.h Here we find the core register architecture and command line handlers for the dap commands implemented in arm_adi_v5.c. These fuiles does not affect any other but cortex_a8.h/c code in OpenOCD. Should be harmless to commit. -- COMPLETE REPLACEMENT Index: src/target/cortex_a8.c Index: src/target/cortex_a8.h This is the target implementation. This code is similar to the CortexM3 and ARM7_9 targets. This replaces the previous nonfunctional cortex_a8 code with something that at least basically works even if it is incomplete. Does not affect any other subsystem, thus harmless to commit. -- Comments This code has been tested with a Flyswatter interface and a BeagleBoard. Under uBoot, virtual memory disabled: + mdw/mww works + load_image/dump_image of a 100k jpeg picture to ram + load_image of a small application (led blink) to ram run using resume startaddr + halt/step/resum works (R1606) + breakpoints works Testing is not exstensive but on my system it works. After Linux is started things get WEIRD !!! I know that there are lots of very raw edges but instead of holding off until it is nice and clean, I submit this for everybody to play with. Good luck and have fun. Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
On Tue, Jul 7, 2009 at 8:57 AM, Dominicdominic.r...@gmx.de wrote: On Monday 06 July 2009 23:31:47 Øyvind Harboe wrote: Hmmm 838 - 729 covers a *lot* of changes but nothing that stands out as a suspect. If you have time to narrow this down further then that would be *great*. 788 has the startup tcl script embedded. That could be the problem you are seing in 783. You were right, 788 worked again - but not with reset halt debugging though. I hope to be able to run some more tests or maybe read up on the failing code this evening Could you be seing a srst_pulls_trst problem too? It solved all the i.MX27 ailments... -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
On Wednesday 08 July 2009 08:42:23 Øyvind Harboe wrote: On Tue, Jul 7, 2009 at 8:57 AM, Dominicdominic.r...@gmx.de wrote: On Monday 06 July 2009 23:31:47 Øyvind Harboe wrote: Hmmm 838 - 729 covers a *lot* of changes but nothing that stands out as a suspect. If you have time to narrow this down further then that would be *great*. 788 has the startup tcl script embedded. That could be the problem you are seing in 783. You were right, 788 worked again - but not with reset halt debugging though. I hope to be able to run some more tests or maybe read up on the failing code this evening Could you be seing a srst_pulls_trst problem too? It solved all the i.MX27 ailments... R729 works just fine, without srst_pulls_trst. If the target required srst_pulls_trst reset halt wouldn't work at all. I had a brief look at the i.MX27 manual - are you sure it really requires srst_pulls_trst? To me it looks like only POR (power on reset) pulls TRST, but HRESET shouldn't affect TRST. I haven't had time to work on this yesterday, maybe today gets better... Regadrds, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
On Wed, Jul 8, 2009 at 8:50 AM, Dominicdominic.r...@gmx.de wrote: On Wednesday 08 July 2009 08:42:23 Øyvind Harboe wrote: On Tue, Jul 7, 2009 at 8:57 AM, Dominicdominic.r...@gmx.de wrote: On Monday 06 July 2009 23:31:47 Øyvind Harboe wrote: Hmmm 838 - 729 covers a *lot* of changes but nothing that stands out as a suspect. If you have time to narrow this down further then that would be *great*. 788 has the startup tcl script embedded. That could be the problem you are seing in 783. You were right, 788 worked again - but not with reset halt debugging though. I hope to be able to run some more tests or maybe read up on the failing code this evening Could you be seing a srst_pulls_trst problem too? It solved all the i.MX27 ailments... R729 works just fine, without srst_pulls_trst. If the target required srst_pulls_trst reset halt wouldn't work at all. I had a brief look at the i.MX27 manual - are you sure it really requires srst_pulls_trst? I'm not a hardware expert, I had help. See comments in file I copied out of that email w/reference to the page in the manual. I was told that there was no way to reset the CPU without resetting the JTAG controller. This matches my observations: without srst_pulls_trst I get all sorts of weird error messages(including mystery MOE=0xe, etc.). Though, perhaps you're right that srst_pulls_trst is a red herring, but it fixes the problem. If that's the case, then the next question is *why* it fixes the problems :-) -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2471 - trunk/src/jtag
Hi Xiaofan, You asked me what the result of Spencer's patch was under Mac OS X. I tested it against my system this evening and as you will see below, it caused a number of startup faults. It also appears to make the j-link dongle completely unresponsive thereafter. I guess the bigger question is this. Did the Windows version ever suffer from the intermittent startup problem or was this exclusively a problem with Linux/Mac systems? If Windows doesn't need the usb_reset and doesn't suffer from the intermittent issue, doesn't it make more sense to put a conditional around it that excludes that step for windows rather then forcing the device search again? Info : J-Link initialization started / target CPU reset initiated Error: J-Link command 0xde failed (-13) Error: J-Link command 0xdc failed (-13) Error: J-Link command 0x01 failed (-13) Error: J-Link command EMU_CMD_VERSION failed (-13) Info : J-Link JTAG Interface ready Error: J-Link command 0xdd failed (-13) Error: J-Link command 0xdf failed (-13) Error: J-Link setting speed failed (-13) Error: usb_bulk_write failed (requested=6, result=-13) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: usb_bulk_write failed (requested=6, result=-13) Error: jlink_tap_execute, wrong result -107 (expected 1) . . . Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. On 7/7/09 8:18 PM, Gary Carlson gcarl...@carlson-minot.com wrote: Xiaofan, Your statement is correct. Underlying the fancy GUI of Mac OS X is really a variant of the BSD UNIX operating system. So it is not terribly surprising that both Linux and Mac behave similar in this case. Based on past development experiences I have generally observed a problem cross-over rate of about 75% between the two systems. Windows unfortunately is a different story! :) I haven't tried Spencer's patch yet. Unfortunately I had to veer off this effort for most of the day to go deal with another problem on a different project. I will hopefully get a chance to try it later this evening. Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. On 7/7/09 8:03 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Jul 8, 2009 at 10:59 AM, Gary Carlsongcarl...@carlson-minot.com wrote: Hi Xiaofan, The second part of the patch is most certainly critical to Linux and Mac OS X systems. I am less sure about Windows since I don't have anything to test. If the usb_reset instruction is removed, you will find that the intermittent start-up failures that went away with the patch will be back. Other then the reset halt command being broken, my V8 debugger works well and I have experienced no startup failures since. As for the reset halt problem I am trying to find out what is causing that. I see. So Mac OS X behaves similar to Linux. In any case, Spen's patch should work for Linux and Mac OS X along with Windows. It is a proper practice to reopen the USB device after a usb_reset(). Have you tried out his patch? ___ 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] Analog Device AduC70xx support
I have an Aduc7024 here that I can test with. Could you provide instructions on how to reproduce the crash on that target? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] XScale broken in R2495?
Hi, I just did a svn update on my work machine (Debian 5.0). It seems XScale (IXP42x) is broken because OpenOCD can't find the debug handler in the installed location: I did: ./bootstrap ./configure --enable-maintainer-mode --prefix=/opt/openocd \ --enable-parport --enable-parport_ppdev \ --enable-ft2232_libftdi \ CFLAGS=-O2 -Wall -W make make install When running OpenOCD: /opt/openocd/bin/openocd -s ~/.openocd -f altium.cfg -f l54.cfg I get: Error: couldn't open xscale/debug_handler.bin strace shows: open(xscale/debug_handler.bin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/opt/openocd/share/openocd/site/xscale/debug_handler.bin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/opt/openocd/share/openocd/scripts/xscale/debug_handler.bin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/home/mschwing/.openocd/xscale/debug_handler.bin, O_RDONLY) = -1 ENOENT (No such file or directory) debug_handler.bin is installed by make install in /opt/openocd/lib/openocd/xscale/debug_handler.bin which is not where the compiled executable looks for it. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 0/5] Documentation Updates for 0.2.0
The files in this series are meant for review, so feedback may be incorporated in them before I commit them. 1/5 Add comments to top-level files to excuse their Doxygen markup. 2/5 Add microscopic style guide at the end of the PATCH primer. 3/5 Add section to provide some documentation for cross-compiling. 4/5 Add style rule to avoid combining assignment and logical tests. 5/5 Document Maintainers and Testing. --- Summary of Patches 1-5: BUGS |1 PATCHES |4 README| 23 + TODO |1 doc/manual/main.txt | 15 +++ doc/manual/maintainers.txt| 139 + doc/manual/primer/patches.txt | 13 +++ doc/manual/style.txt | 14 +++ doc/manual/testing.txt| 176 ++ 9 files changed, 382 insertions(+), 4 deletions(-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/5] Add comments to top-level files to excuse their Doxygen markup.
Add comments to top-level files to excuse their Doxygen markup. --- BUGS|1 + PATCHES |4 ++-- TODO|1 + 3 files changed, 4 insertions(+), 2 deletions(-) Add comments to top-level files to excuse their Doxygen markup. --- BUGS|1 + PATCHES |4 ++-- TODO|1 + 3 files changed, 4 insertions(+), 2 deletions(-) == only in patch2: unchanged: --- PATCHES (revision 2495) +++ PATCHES (working copy) @@ -1,7 +1,7 @@ +// This file is part of the Doyxgen Developer Manual /** @page patchguide Patch Guidelines -Please mail patches to: - +Please mail patches to: @par openocd-development@lists.berlios.de Note that you can't send patches to that list unless only in patch2: unchanged: --- BUGS (revision 2495) +++ BUGS (working copy) @@ -1,3 +1,4 @@ +// This file is part of the Doyxgen Developer Manual /** @page bugs Bug Reporting Please report bugs by subscribing to the OpenOCD mailing list and only in patch2: unchanged: --- TODO (revision 2495) +++ TODO (working copy) @@ -1,3 +1,4 @@ +// This file is part of the Doyxgen Developer Manual /** @page tasks Pending and Open Tasks This page lists pending and open tasks being considered or worked upon ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/5] Add microscopic style guide at the end of the PATCH primer.
Add microscopic style guide at the end of the PATCH primer. --- patches.txt | 13 + 1 file changed, 13 insertions(+) Add microscopic style guide at the end of the PATCH primer. --- patches.txt | 13 + 1 file changed, 13 insertions(+) == only in patch2: unchanged: --- doc/manual/primer/patches.txt (revision 2495) +++ doc/manual/primer/patches.txt (working copy) @@ -204,6 +204,19 @@ work on the project voluntarily and without compensation for the time that they spend doing these tasks. +...@section primerpatchguide Guidelines for Submitting Patches + +- Each patch file should contain: + - A commit description that describes all of the changes. + - A separator line that contains three hyphens: code---/code + - A summary of the changes produced by diffstat (optional) + - Another separator line (optional) + - The actual patch contents, containing a single change. + +- Each patch series should include: + - A summary of the patches in the series. + - Logically-related patches that contain incremental changes. + */ /** @file This file contains the @ref primerpatches page. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 3/5] Add section to provide some documentation for cross-compiling.
Add section to provide some documentation for cross-compiling. --- README | 23 +++ 1 file changed, 23 insertions(+) Add section to provide some documentation for cross-compiling. --- README | 23 +++ 1 file changed, 23 insertions(+) == only in patch2: unchanged: --- README (revision 2495) +++ README (working copy) @@ -166,6 +166,29 @@ final (optional) step, ``make install'', places all of the files in the required location. +Cross-Compiling Options +--- + +To cross-compile, you must specify both --build and --host options to +the 'configure' script. For example, you can configure OpenOCD to +cross-compile on a x86 Linux host to run on Windows (MinGW32), you could +use the following configuration options: + + ./configure --build=i686-pc-linux-gnu --host=i586-mingw32msvc ... + +Likewise, the following options allow OpenOCD to be cross-compiled for +an ARM target on the same x86 host: + + ./configure --build=i686-pc-linux-gnu --host=arm-elf ... + +Both must be specified to work around bugs in autoconf. + +Scripts for producing ARM cross-compilers can be found on the web with a +little searching. A script to produce an x86 Linux-hosted MinGW32 +cross-compiler can be downloaded from the following URL: + + http://www.mingw.org/wiki/LinuxCrossMinGW + Configuration Options - ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 4/5] Add style rule to avoid combining assignment and logical tests.
Add style rule to avoid combining assignment and logical tests. --- style.txt | 14 ++ 1 file changed, 14 insertions(+) Add style rule to avoid combining assignment and logical tests. --- style.txt | 14 ++ 1 file changed, 14 insertions(+) == only in patch2: unchanged: --- doc/manual/style.txt (revision 2495) +++ doc/manual/style.txt (working copy) @@ -107,6 +107,20 @@ ... } @endcode +- Separate assignment and logical test statements. In other words, you +should write statements like the following: +...@code +// separate statements should be preferred +result = foo(); +if (ERROR_OK != result) + ... +...@endcode +More directly, do @b not combine these kinds of statements: +...@code +// Combined statements should be avoided +if (ERROR_OK != (result = foo())) + return result; +...@endcode */ /** @page styledoxygen Doxygen Style Guide ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: woensdag 8 juli 2009 0:35 To: Øyvind Harboe Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] 0.2.0 release... on hold? On Wed, 2009-07-08 at 00:14 +0200, Øyvind Harboe wrote: We need to find some balance. Right now, the presses are too heavily biased toward development to the extent that release suffers badly. I definitely want to see a reset of the release timeout counter when we discover such problems as we have seen in the last week. The step bug alone would have made *all* the regression test scripts fail... I wouldn't even want to ask Michael Fischer to run the regression test suite without that one in place... Right, so I do want to make it clear that some of these are entirely legitimate bugs that you are fixing. No dispute about that. In that regard, I am happy to reset the release deadline while we consider the patches. However, there does need to be a limit to the number of resets that we allow for new issues. If I may be very blunt: I don't think we are very close to a 0.2.0 release. It seems (based on bug reports) the recent changes broke some of the existing functionality. That needs to be tested fixed first. IMHO release 0.2.0 should have at least the same functionality that 0.1.0 had. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] aduc702x error handling fixes
On Wed, 2009-07-08 at 10:04 +0200, Øyvind Harboe wrote: ### Eclipse Workspace Patch 1.0 #P openocd Index: src/flash/aduc702x.c === --- src/flash/aduc702x.c(revision 2490) +++ src/flash/aduc702x.c(working copy) [snip] + if ((retval=target_write_buffer(target, aduc702x_info-write_algorithm-address, +sizeof(aduc702x_flash_write_code), (uint8_t*)aduc702x_flash_write_code))!=ERROR_OK) Separate assignment and logical test expressions into two statements. See my just-posted patch to add a style rule to this effect for details. [snip] + if ((retval=target_write_buffer(target, source-address, thisrun_count * 2, buffer))!=ERROR_OK) Ditto [snip] - retval = ERROR_FLASH_OPERATION_FAILED; + if ((buf_get_u32(reg_params[3].value, 0, 32) 1) != 1) Ditto. Thanks, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] aduc702x error handling fixes
I'll do this before committing, awaiting comments on the functionality first. -- Øyvind Harboe Embedded software and hardware consulting services http://www.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 release... on hold?
If I may be very blunt: I don't think we are very close to a 0.2.0 release. It seems (based on bug reports) the recent changes broke some of the existing functionality. That needs to be tested fixed first. IMHO release 0.2.0 should have at least the same functionality that 0.1.0 had. Regressions are at the very top of the list of reasons to postpone 0.2.0. Please report outstanding issues you find to the list. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] aduc702x error handling fixes
[snip] - retval = ERROR_FLASH_OPERATION_FAILED; + if ((buf_get_u32(reg_params[3].value, 0, 32) 1) != 1) Ditto. I didn't touch this part of the code, so I'm leaving it alone. Although desirable, such no-op cleanup's is best left to a separate commit. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2497 - trunk
On Wed, 2009-07-08 at 12:25 +0200, oharboe at BerliOS wrote: Author: oharboe Date: 2009-07-08 12:25:39 +0200 (Wed, 08 Jul 2009) New Revision: 2497 Modified: trunk/TODO Log: Xscale installation regression entered Modified: trunk/TODO === --- trunk/TODO2009-07-08 10:25:23 UTC (rev 2496) +++ trunk/TODO2009-07-08 10:25:39 UTC (rev 2497) @@ -97,6 +97,10 @@ @section thelisttargets Target Support +- regression: xscale does not place debug_handler.bin into the right spot: + +https://lists.berlios.de/pipermail/openocd-development/2009-July/009338.html + - general layer cleanup: @par https://lists.berlios.de/pipermail/openocd-development/2009-May/006590.html - regression: reset halt between 729(works) and 788(fails): @par Don't add blank lines in lists, and use @par at the end of the line to get the proper formatting for the link. The blank lines separates the items and causes Doxygen to generate separate lists, whereas my suggestions preserve the integrity of the emitted lists. This is particular important for numbered lists, as the discontinuities become apparent when all items are labeled 1). Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
On Wed, 2009-07-08 at 12:06 +0200, Nico Coesel wrote: -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: woensdag 8 juli 2009 0:35 To: Øyvind Harboe Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] 0.2.0 release... on hold? On Wed, 2009-07-08 at 00:14 +0200, Øyvind Harboe wrote: We need to find some balance. Right now, the presses are too heavily biased toward development to the extent that release suffers badly. I definitely want to see a reset of the release timeout counter when we discover such problems as we have seen in the last week. The step bug alone would have made *all* the regression test scripts fail... I wouldn't even want to ask Michael Fischer to run the regression test suite without that one in place... Right, so I do want to make it clear that some of these are entirely legitimate bugs that you are fixing. No dispute about that. In that regard, I am happy to reset the release deadline while we consider the patches. However, there does need to be a limit to the number of resets that we allow for new issues. If I may be very blunt: I don't think we are very close to a 0.2.0 release. It seems (based on bug reports) the recent changes broke some of the existing functionality. That needs to be tested fixed first. I think that we need to fix the bugs that we have spotted, but each release window has its limits. The 7/1 deadline had been discussed in on the list more than once, and I am fairly certain that I gave ample warning to the community in the past week or so. The late rush and subsequent delays are simultaneously expected and disappointing. IMHO release 0.2.0 should have at least the same functionality that 0.1.0 had. This kind of expectation does not hold indefinitely, as not even the Linux kernel maintains support for all platforms indefinitely. I bet every minor release sees a regressions in a small part of the tree. Given that OpenOCD shares the same hardware testing requirements, I think it would be insane to expect that we never have regressions for some platforms. Moreover, some of the reset bugs being discussed appear to have been introduced before the 0.1.0 release. We can't wait for everyone that missed the release window, when others get their work in on time. That is simply not fair to the maintainers that are keeping up with the schedule. This is why the world has deadlines, and there will always be consequences for missing them. Fortunately, we can make new releases in due course, so any mistakes will be corrected with sufficient patience from the community. All of this is for the future. For now, we're playing things by ear, and it sounds like we need to give 0.2.0 a little more time to brew. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale broken in R2495?
How is the attached patch?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/helper/Makefile.am
===
--- src/helper/Makefile.am (revision 2490)
+++ src/helper/Makefile.am (working copy)
@@ -1,6 +1,7 @@
AM_CPPFLAGS = \
-I$(top_srcdir)/src/server \
-I$(top_srcdir)/src/target \
+ -DPKGLIBDIR=\$(pkglibdir)\ \
-DPKGDATADIR=\$(pkgdatadir)\
METASOURCES = AUTO
Index: src/helper/options.c
===
--- src/helper/options.c(revision 2490)
+++ src/helper/options.c(working copy)
@@ -105,6 +105,7 @@
/// @todo Implement @c add_script_search_dir(${HOME}/.openocd).
add_script_search_dir(PKGDATADIR /site);
add_script_search_dir(PKGDATADIR /scripts);
+ add_script_search_dir(PKGLIBDIR);
#endif
return ERROR_OK;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Would you like *your* problems fixed for 0.2?
If yes, then test with svn head *now* and give feedback ASAP. We're trying to push out 0.2, but we'll wait until we have fixed all *serious* regressions since 0.1. If you have a known regression in svn head vs. 0.1 that is not in the TODO list, then post a reminder to the list about the problem. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale broken in R2495?
Øyvind Harboe wrote: How is the attached patch? Works fine. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale broken in R2495?
On Wed, 2009-07-08 at 12:47 +0200, Øyvind Harboe wrote:
How is the attached patch?
The NEWS file details the migration of the installed scripts from
$(pkglibdir) to $(pkgdatadir)/scripts; the former should not be used
anymore, and custom scripts migrated into $(pkgdatadir)/site/. This
patch will prevent us from forcing this migration, as the old location
will continue to be be used. So it might fix the bug, but it seems bad.
However, this particular example shows how our searching for files may
be insufficient. Presently, there is no way to enforce a separation
between script files and executable files (if such is desired).
The effect of this would be to allow a site to install read-only binary
files that may be used by read-write scripts. In reality, I think ACLs
make this proposition more meaningful, but others can comment on the
concept of privilege separation. Am I taking that idea too far here?
In this light, I would rather see us add a mechanism to find the two
types of file, such that the search paths for each are separated.
Script files can be searched using one list of paths, and binary files
from another. Internally, it seems like we could switch search paths
based on the filename extension being loaded.
At the simplest, this would mean that .cfg and .tcl files use search
paths with $(pkgdatadir), and other files use search paths with
$(pkglibdir). Of course, a simple configuration could list the same
paths in both (e.g. ${HOME}/some/project), but I think this seems like a
better technical solution for the base installation itself.
Does this seem sane? If so, I would like to see you add /// @todo
comments at each of the points of modification, to remind us to remove
these and replace them with a mechanism like the one I described. For
now, your patch may be a necessary hackity-hack-hack-hack. Of course,
this label assumes that others will see this situation the same as I do.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale broken in R2495?
On Wed, Jul 8, 2009 at 1:55 PM, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-07-08 at 12:47 +0200, Øyvind Harboe wrote: How is the attached patch? The NEWS file details the migration of the installed scripts from $(pkglibdir) to $(pkgdatadir)/scripts; the former should not be used anymore, and custom scripts migrated into $(pkgdatadir)/site/. This patch will prevent us from forcing this migration, as the old location will continue to be be used. So it might fix the bug, but it seems bad. However, this particular example shows how our searching for files may be insufficient. Presently, there is no way to enforce a separation between script files and executable files (if such is desired). I don't think we need or want to distinguish between the debug_handler.bin and other executables for the target(e.g. at91eb40a flash driver) and scripts. The effect of this would be to allow a site to install read-only binary files that may be used by read-write scripts. In reality, I think ACLs make this proposition more meaningful, but others can comment on the concept of privilege separation. Am I taking that idea too far here? To the host OS the target executables are not executables, are they? Does this seem sane? I don't understand why you need or want to distinguish between target executables and scripts. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale broken in R2495?
On Wed, 2009-07-08 at 14:03 +0200, Øyvind Harboe wrote: On Wed, Jul 8, 2009 at 1:55 PM, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-07-08 at 12:47 +0200, Øyvind Harboe wrote: How is the attached patch? The NEWS file details the migration of the installed scripts from $(pkglibdir) to $(pkgdatadir)/scripts; the former should not be used anymore, and custom scripts migrated into $(pkgdatadir)/site/. This patch will prevent us from forcing this migration, as the old location will continue to be be used. So it might fix the bug, but it seems bad. However, this particular example shows how our searching for files may be insufficient. Presently, there is no way to enforce a separation between script files and executable files (if such is desired). I don't think we need or want to distinguish between the debug_handler.bin and other executables for the target(e.g. at91eb40a flash driver) and scripts. The effect of this would be to allow a site to install read-only binary files that may be used by read-write scripts. In reality, I think ACLs make this proposition more meaningful, but others can comment on the concept of privilege separation. Am I taking that idea too far here? To the host OS the target executables are not executables, are they? Does this seem sane? I don't understand why you need or want to distinguish between target executables and scripts. Let's give this some time to stew. Clearly, I did not manage to convince myself entirely, and it's not 0.2.0 material. I still dislike the idea of having both pkglibdir and pkgdatadir in the search path. One distinction between the two would be the scripts run on the host, but the binaries run on the target. A parallel might be the difference between PATH and LDPATH, but I think that comparison is not entirely right. I hope this gives some perspective on my thinking here. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale broken in R2495?
Let's give this some time to stew. Clearly, I did not manage to convince myself entirely, and it's not 0.2.0 material. I still dislike the idea of having both pkglibdir and pkgdatadir in the search path. I would have thought the right spot for target executables was in the pkgdatadir. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Wed, 2009-07-08 at 09:41 +0200, Øyvind Harboe wrote: I have an Aduc7024 here that I can test with. Could you provide instructions on how to reproduce the crash on that target? It works without crashing now! The elf file does have a problem. I will send it to you. I did not change any setting to remove unnecessary sections from the output. tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Wed, Jul 8, 2009 at 2:22 PM, Thomas A. Moultont...@moulton.us wrote: On Wed, 2009-07-08 at 09:41 +0200, Øyvind Harboe wrote: I have an Aduc7024 here that I can test with. Could you provide instructions on how to reproduce the crash on that target? It works without crashing now! With or without the patch? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale broken in R2495?
On Wed, Jul 8, 2009 at 1:11 PM, Michael Schwingenrincew...@discworld.dascon.de wrote: Øyvind Harboe wrote: How is the attached patch? Works fine. The other workaround is to add that path on the command line to OpenOCD. Perhaps we should postpone this patch until after 0.2. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fix flash programming w/aduc702x
This patch fixes the broken flash programming w/workarea enabled.
Please test report.
These bugs explain the intermittent SEGFAULT's reported +
that flash programming worked some of the time.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/flash/aduc702x.c
===
--- src/flash/aduc702x.c(revision 2490)
+++ src/flash/aduc702x.c(working copy)
@@ -193,6 +193,11 @@
return ERROR_FLASH_OPERATION_FAILED;
}
+/* If this fn returns ERROR_TARGET_RESOURCE_NOT_AVAILABLE, then the caller can
fall
+ * back to another mechanism that does not require onboard RAM
+ *
+ * Caller should not check for other return values specifically
+ */
static int aduc702x_write_block(struct flash_bank_s *bank, uint8_t *buffer,
uint32_t offset, uint32_t count)
{
aduc702x_flash_bank_t *aduc702x_info = bank-driver_priv;
@@ -204,6 +209,12 @@
armv4_5_algorithm_t armv4_5_info;
int retval = ERROR_OK;
+ if (((count%2)!=0)||((offset%2)!=0))
+ {
+ LOG_ERROR(write block must be multiple of two bytes in offset
length);
+ return ERROR_FAIL;
+ }
+
/* parameters:
r0 - address of source data (absolute)
@@ -249,8 +260,12 @@
return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
};
- target_write_buffer(target, aduc702x_info-write_algorithm-address,
+ retval=target_write_buffer(target,
aduc702x_info-write_algorithm-address,
sizeof(aduc702x_flash_write_code),
(uint8_t*)aduc702x_flash_write_code);
+ if (retval!=ERROR_OK)
+ {
+ return retval;
+ }
/* memory buffer */
while (target_alloc_working_area(target, buffer_size, source) !=
ERROR_OK)
@@ -279,12 +294,16 @@
while (count 0)
{
- uint32_t thisrun_count = (count (buffer_size / 2)) ?
(buffer_size / 2) : count;
+ uint32_t thisrun_count = (count buffer_size) ? buffer_size :
count;
- target_write_buffer(target, source-address, thisrun_count * 2,
buffer);
+ retval=target_write_buffer(target, source-address,
thisrun_count, buffer);
+ if (retval!=ERROR_OK)
+ {
+ break;
+ }
buf_set_u32(reg_params[0].value, 0, 32, source-address);
- buf_set_u32(reg_params[1].value, 0, 32, thisrun_count);
+ buf_set_u32(reg_params[1].value, 0, 32, thisrun_count/2);
buf_set_u32(reg_params[2].value, 0, 32, address);
buf_set_u32(reg_params[4].value, 0, 32, 0xF800);
@@ -294,17 +313,19 @@
1, armv4_5_info)) != ERROR_OK)
{
LOG_ERROR(error executing aduc702x flash write
algorithm);
- retval = ERROR_FLASH_OPERATION_FAILED;
break;
}
- if ((buf_get_u32(reg_params[3].value, 0, 32) 1) != 1) {
- retval = ERROR_FLASH_OPERATION_FAILED;
+ if ((buf_get_u32(reg_params[3].value, 0, 32) 1) != 1)
+ {
+ /* FIX what does this mean??? replace w/sensible
error message */
+ LOG_ERROR(aduc702x detected error writing flash);
+ retval = ERROR_FAIL;
break;
}
- buffer += thisrun_count * 2;
- address += thisrun_count * 2;
+ buffer += thisrun_count;
+ address += thisrun_count;
count -= thisrun_count;
}
@@ -382,14 +403,9 @@
return ERROR_FLASH_OPERATION_FAILED;
}
}
-else if (retval == ERROR_FLASH_OPERATION_FAILED)
-{
-LOG_ERROR(flash block writing failed);
-return ERROR_FLASH_OPERATION_FAILED;
-}
}
-return ERROR_OK;
+return retval;
}
static int aduc702x_probe(struct flash_bank_s *bank)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/5] Add comments to top-level files to excuse their Doxygen markup.
On Wed, Jul 8, 2009 at 6:05 PM, Zach Welchz...@superlucidity.net wrote: Add comments to top-level files to excuse their Doxygen markup. --- BUGS | 1 + PATCHES | 4 ++-- TODO | 1 + 3 files changed, 4 insertions(+), 2 deletions(-) The TODO file has the following section. @section thelistbs Boundary Scan Support - add STAPL support? - add BSDL support? A few possible options for the above: -# Fake a TCL equivalent? -# Integrate an existing library? -# Write a new C implementation a la Jim? Is this a la Jim English? Is it aka Jim? or also know as Jim? I am not a native speaker of English though. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Please remove contrib\libftdi
I am now looking at the OpenOCD source codes and find out that there is one patch file for libftdi 0.12 by Spen. As the README file stated that Windows support of libftdi is since version 0.14 and libftdi 0.14 has already the patches implemented, I think this directory contrib\libftdi is no longer necessary. Please remove it. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fix xscale debug_handler.bin take #2
Testingcomments appreciated!
I'm thinking that target executables should be placed
into the same folder as scripts.
It's not really executables from the host OS's point of
view, it's just data that ships w/OpenOCD and that
OpenOCD uses.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/helper/options.c
===
--- src/helper/options.c(revision 2490)
+++ src/helper/options.c(working copy)
@@ -105,6 +105,8 @@
/// @todo Implement @c add_script_search_dir(${HOME}/.openocd).
add_script_search_dir(PKGDATADIR /site);
add_script_search_dir(PKGDATADIR /scripts);
+ /// @todo where should target executables be placed?? For now in the
PKGDATADIR
+ add_script_search_dir(PKGDATADIR);
#endif
return ERROR_OK;
}
Index: src/target/Makefile.am
===
--- src/target/Makefile.am (revision 2490)
+++ src/target/Makefile.am (working copy)
@@ -95,8 +95,8 @@
mips32_dmaacc.h \
avrt.h
-nobase_dist_pkglib_DATA =
-nobase_dist_pkglib_DATA += xscale/debug_handler.bin
-nobase_dist_pkglib_DATA += ecos/at91eb40a.elf
+nobase_dist_pkgdata_DATA =
+nobase_dist_pkgdata_DATA += xscale/debug_handler.bin
+nobase_dist_pkgdata_DATA += ecos/at91eb40a.elf
MAINTAINERCLEANFILES = $(srcdir)/Makefile.in
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] libusb-win32 svn released as 0.1.12.2
On Wed, Jul 8, 2009 at 7:28 AM, Xiaofan Chenxiaof...@gmail.com wrote: http://www.nabble.com/Possibility-to-release-the-current-SVN-version-as-0.1.12.2-td24141073.html The author has accepted my suggestion released the latest svn of libusb-win32 0.1 branch as 0.1.12.2. Download: http://sourceforge.net/projects/libusb-win32/files/ This version solved the problem of composite device (like the FT2232x based JTAG debugger). So now we do not need to build libusb-win32 by ourself to use the updated libusb0.sys. 64bit driver and lib (for XP 64bit) are also included. But I think the lib is only for MSVC (because we need DDK/WDK to build the 64bit driver and library and they use MSVC). And I think last time the conclusion from the discussion is that OpenOCD will not support MSVC anytime soon. According to Stefan Meyer, there is a way to use the 64bit DLL with MinGW. http://www.nabble.com/Possibility-to-release-the-current-SVN-version-as-0.1.12.2-td24141073.html Yes, the 64bit version is compiled with MSVC but you can use it with MinGW: * add /lib/dynamic/libusb_dyn.c to your project * in line 25 replace libusb0.dll with libusb0_x64.dll * compile * the 64bit DLL will now be loaded dynamically at runtime This method should work with any compiler on any system. -- 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] [Openocd-svn] r2471 - trunk/src/jtag
On Wed, Jul 8, 2009 at 2:11 PM, Gary Carlsongcarl...@carlson-minot.com wrote: You asked me what the result of Spencer's patch was under Mac OS X. I tested it against my system this evening and as you will see below, it caused a number of startup faults. It also appears to make the j-link dongle completely unresponsive thereafter. I guess the bigger question is this. Did the Windows version ever suffer from the intermittent startup problem or was this exclusively a problem with Linux/Mac systems? I have not tried J-Link under Windows recently. At home, I run Linux more often than Windows. But I tried to remove your line of usb_reset() patch and the startup error comes back from time to time. It is not a fatal error but certainly not that nice. So indeed your patch is necessary. But maybe there is a better way to do it without affecting the usb_handle. I will try out some other ideas. mc...@ubuntu904:~/Desktop/build/openocd/jlinkv3$ openocd -f lpc-p2148.cfg Open On-Chip Debugger 0.2.0-in-development (2009-07-08-22:36) svn:2498M $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS RCLK - adaptive jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 Info : J-Link initialization started / target CPU reset initiated Error: J-Link command EMU_CMD_VERSION impossible return length 0x2d4a Error: J-Link command EMU_CMD_VERSION failed (-110) Info : J-Link JTAG Interface ready Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : JTAG Tap/device matched If Windows doesn't need the usb_reset and doesn't suffer from the intermittent issue, doesn't it make more sense to put a conditional around it that excludes that step for windows rather then forcing the device search again? Maybe Spen can answer this. -- 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] [Openocd-svn] r2471 - trunk/src/jtag
You asked me what the result of Spencer's patch was under Mac OS X. I tested it against my system this evening and as you will see below, it caused a number of startup faults. It also appears to make the j-link dongle completely unresponsive thereafter. I guess the bigger question is this. Did the Windows version ever suffer from the intermittent startup problem or was this exclusively a problem with Linux/Mac systems? If Windows doesn't need the usb_reset and doesn't suffer from the intermittent issue, doesn't it make more sense to put a conditional around it that excludes that step for windows rather then forcing the device search again? Info : J-Link initialization started / target CPU reset initiated Error: J-Link command 0xde failed (-13) Error: J-Link command 0xdc failed (-13) Error: J-Link command 0x01 failed (-13) Error: J-Link command EMU_CMD_VERSION failed (-13) Info : J-Link JTAG Interface ready Error: J-Link command 0xdd failed (-13) Error: J-Link command 0xdf failed (-13) Error: J-Link setting speed failed (-13) Error: usb_bulk_write failed (requested=6, result=-13) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: usb_bulk_write failed (requested=6, result=-13) Error: jlink_tap_execute, wrong result -107 (expected 1) . . . Strange, i fail to see why my patch would cause this. I have only tested the patch on linux and win32 and it works fine on these. All the patch does is re-enumerate after the usb_reset. Could you step through and see that a valid handle is returned? Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Wed, 2009-07-08 at 14:43 +0200, Øyvind Harboe wrote:
On Wed, Jul 8, 2009 at 2:22 PM, Thomas A. Moultont...@moulton.us wrote:
On Wed, 2009-07-08 at 09:41 +0200, Øyvind Harboe wrote:
I have an Aduc7024 here that I can test with.
Could you provide instructions on how to reproduce the crash on
that target?
It works without crashing now!
With or without the patch?
svn head plus
Index: src/flash/flash.c
===
--- src/flash/flash.c (revision 2498)
+++ src/flash/flash.c (working copy)
@@ -1091,6 +1091,12 @@
/* allocate buffer */
buffer = malloc(run_size);
+if (buffer == NULL)
+{
+LOG_ERROR(Out of memory allocating %d bytes,
run_size);
+return ERROR_FAIL;
+}
+
buffer_size = 0;
/* read sections to the buffer */
Should I try the other patch you sent?
Tom
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix flash programming w/aduc702x
On Wed, 2009-07-08 at 16:10 +0200, Øyvind Harboe wrote: This patch fixes the broken flash programming w/workarea enabled. Please test report. These bugs explain the intermittent SEGFAULT's reported + that flash programming worked some of the time. Pardon my ignorance, but is there an easy way to automatically apply this patch? tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix flash programming w/aduc702x
On Wed, Jul 8, 2009 at 5:20 PM, Thomas A. Moultont...@moulton.us wrote: On Wed, 2009-07-08 at 16:10 +0200, Øyvind Harboe wrote: This patch fixes the broken flash programming w/workarea enabled. Please test report. These bugs explain the intermittent SEGFAULT's reported + that flash programming worked some of the time. Pardon my ignorance, but is there an easy way to automatically apply this patch? patch -p0 /cygdrive/c/temp/fixaduc702xflash.txt NB! Note that without this fix you'll get *intermittant* crashes and flashing *could* work in some cases. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix flash programming w/aduc702x
On Wed, 2009-07-08 at 17:31 +0200, Øyvind Harboe wrote: On Wed, Jul 8, 2009 at 5:20 PM, Thomas A. Moultont...@moulton.us wrote: On Wed, 2009-07-08 at 16:10 +0200, Øyvind Harboe wrote: This patch fixes the broken flash programming w/workarea enabled. Please test report. These bugs explain the intermittent SEGFAULT's reported + that flash programming worked some of the time. Pardon my ignorance, but is there an easy way to automatically apply this patch? patch -p0 /cygdrive/c/temp/fixaduc702xflash.txt NB! Note that without this fix you'll get *intermittant* crashes and flashing *could* work in some cases. Excellent! It works fine! Thanks. Now to build a windows version. tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Mac OS X cross-compiler not finding system include files?
Hi Maróy, I do development work on Mac OS X Leopard and I ran into a lot of issues like this getting a cross-compiler to work properly in the past. I finally succeeded, but I had to spend three weeks making and testing a custom script to build cross gcc. I don't know if it will help you, but if you are interested I could send that to you and you can try to build gcc with the script. My script is tested with arm, but it will likely work with others if you want to give it a try. Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. On 7/8/09 8:48 AM, Maróy Ákos a...@maroy.hu wrote: Kai, ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/5] Add comments to top-level files to excuse their Doxygen markup.
On Wednesday 08 July 2009, Xiaofan Chen wrote: -# Write a new C implementation a la Jim? Is this a la Jim English? Is it aka Jim? or also know as Jim? I am not a native speaker of English though. It's a borrowing from French, where a la would be kind of odd. Best change to , as done with Jim? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/5] Documentation Updates for 0.2.0
On Wednesday 08 July 2009, Zach Welch wrote: The files in this series are meant for review, so feedback may be incorporated in them before I commit them. 1/5 Add comments to top-level files to excuse their Doxygen markup. 2/5 Add microscopic style guide at the end of the PATCH primer. 3/5 Add section to provide some documentation for cross-compiling. 4/5 Add style rule to avoid combining assignment and logical tests. 5/5 Document Maintainers and Testing. I'll ACK #s 1-4. #5 seems like two significant patches combined into one, and they seem like they each need more review ... --- Summary of Patches 1-5: BUGS |1 PATCHES |4 README| 23 + TODO |1 doc/manual/main.txt | 15 +++ doc/manual/maintainers.txt| 139 + doc/manual/primer/patches.txt | 13 +++ doc/manual/style.txt | 14 +++ doc/manual/testing.txt| 176 ++ 9 files changed, 382 insertions(+), 4 deletions(-) ___ 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] XScale broken in R2495?
On Wednesday 08 July 2009, Øyvind Harboe wrote: I don't understand why you need or want to distinguish between target executables and scripts. As a rule, a script can be maintained with a text editor but a binary can't be ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale broken in R2495?
On Wednesday 08 July 2009, Michael Schwingen wrote: XScale (IXP42x) is broken I reported not that long ago that PXA 255 is broken too ... it doesn't seem to be able to detect the chip in the JTAG chain. It's not clear to me if that was a *regression* since the 0.1.0 release though. It may have been years since it worked. because OpenOCD can't find the debug handler Were it only that simple. ;) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Strange problem with LPC2103
I have a very simple code which just blinks the LED. The code itself is
fine.
When I upload the code and just run it everything is fine. When I try to
debug the same code that I've uploaded before (flash is not modified)
some registers have some funny values which make the code work wrong.
When I close OpenOCD and reset the chip again everything works fine...
WTF?
I've done some investigation and everything is even stranger...
I use GDB Hardware Debugging plugin in Eclipse. I put a breakpoint at main.
When the core hits the breakpoint I inspect the registers:
reg
(11) r11 (/32): 0x41F9 (dirty: 0, valid: 1)
(13) r13_usr (/32): 0x41EC (dirty: 0, valid: 1)
R11 and SP are the register that miraculously have such strange values,
because before main there are just three lines that modify them:
0x00e8 main: push {r11, lr}
0x00ec main+4: add r11, sp, #4 ; 0x4
0x00f0 main+8: sub sp, sp, #8 ; 0x8
(the SP is setup in the startup of course, the value for that is
0x4200. That's pretty easy to count that R11 should be 0x41FC
and SP should be ...1F0.
Now the funny part... When I put my first breakpoint at Reset_Handler
(that's exactly what you think), and then put breakpoint at the first
line that modifies R11 (the first one of the three above) everything
works... The reg dump at the same point as before (3 lines further, at
the beginning of main):
(11) r11 (/32): 0x41FC (dirty: 0, valid: 1)
(13) r13_usr (/32): 0x41F0 (dirty: 0, valid: 1)
When I reset and stop at Reset_Handler, then run to main directly
without that breakpoint in-the-middle - the reg values are wrong /;
I've tried OpenOCD-r2498, 0.1.0 and some revs in between - the same
I've tried GDB from the most recent CodeSourcery and from some older
version of Yagarto - the same.
When I close OpenOCD and reset the chip the code works fine. During the
whole process the contents of flash were exactly the same...
Any ideas? Any help? Who should I blame?
Thx in advance...
4\/3!!
full register dump at the beginning of main (only R11 and SP are
different...):
WRONG:
(0) r0 (/32): 0x00E8 (dirty: 1, valid: 1)
(1) r1 (/32): 0x4000 (dirty: 1, valid: 1)
(2) r2 (/32): 0x4000 (dirty: 0, valid: 1)
(3) r3 (/32): 0x4000 (dirty: 0, valid: 1)
(4) r4 (/32): 0x (dirty: 0, valid: 1)
(5) r5 (/32): 0x (dirty: 0, valid: 1)
(6) r6 (/32): 0x (dirty: 0, valid: 1)
(7) r7 (/32): 0x (dirty: 0, valid: 1)
(8) r8 (/32): 0x (dirty: 0, valid: 1)
(9) r9 (/32): 0x (dirty: 0, valid: 1)
(10) r10 (/32): 0x (dirty: 0, valid: 1)
(11) r11 (/32): 0x41F5 (dirty: 0, valid: 1)
(12) r12 (/32): 0x (dirty: 0, valid: 1)
(13) r13_usr (/32): 0x41E8 (dirty: 0, valid: 1)
(14) lr_usr (/32): 0x00B0 (dirty: 0, valid: 1)
(15) pc (/32): 0x00F4 (dirty: 1, valid: 1)
(16) r8_fiq (/32): 0x (dirty: 0, valid: 0)
(17) r9_fiq (/32): 0x (dirty: 0, valid: 0)
(18) r10_fiq (/32): 0x (dirty: 0, valid: 0)
(19) r11_fiq (/32): 0x (dirty: 0, valid: 0)
(20) r12_fiq (/32): 0x (dirty: 0, valid: 0)
(21) r13_fiq (/32): 0x (dirty: 0, valid: 0)
(22) lr_fiq (/32): 0x (dirty: 0, valid: 0)
(23) r13_irq (/32): 0x (dirty: 0, valid: 0)
(24) lr_irq (/32): 0x (dirty: 0, valid: 0)
(25) r13_svc (/32): 0x4200 (dirty: 0, valid: 0)
(26) lr_svc (/32): 0x7FFFE35F (dirty: 0, valid: 0)
(27) r13_abt (/32): 0x (dirty: 0, valid: 0)
(28) lr_abt (/32): 0x (dirty: 0, valid: 0)
(29) r13_und (/32): 0x (dirty: 0, valid: 0)
(30) lr_und (/32): 0x (dirty: 0, valid: 0)
(31) cpsr (/32): 0x6010 (dirty: 0, valid: 1)
(32) spsr_fiq (/32): 0x (dirty: 0, valid: 0)
(33) spsr_irq (/32): 0x (dirty: 0, valid: 0)
(34) spsr_svc (/32): 0x0010 (dirty: 0, valid: 0)
(35) spsr_abt (/32): 0x (dirty: 0, valid: 0)
(36) spsr_und (/32): 0x (dirty: 0, valid: 0)
(37) debug_ctrl (/6): 0x05 (dirty: 0, valid: 1)
(38) debug_status (/5): 0x09 (dirty: 0, valid: 0)
(39) comms_ctrl (/32): 0x4000 (dirty: 0, valid: 0)
(40) comms_data (/32): 0x (dirty: 0, valid: 0)
(41) watch 0 addr value (/32): 0x00F4 (dirty: 0, valid: 1)
(42) watch 0 addr mask (/32): 0x0003 (dirty: 0, valid: 1)
(43) watch 0 data value (/32): 0x (dirty: 0, valid: 0)
(44) watch 0 data mask (/32): 0x (dirty: 0, valid: 1)
(45) watch 0 control value (/32): 0x (dirty: 0, valid: 1)
(46) watch 0 control mask (/32): 0x00F7 (dirty: 0, valid: 1)
(47) watch 1 addr value (/32): 0x00F4 (dirty: 0, valid: 1)
(48) watch 1 addr mask (/32): 0x0003 (dirty: 0, valid: 1)
(49) watch 1 data value (/32): 0x (dirty: 0, valid: 0)
(50) watch 1 data mask (/32): 0x (dirty: 0, valid: 1)
(51) watch 1 control value (/32): 0x (dirty: 0, valid: 1)
(52) watch 1 control mask (/32): 0x00F7 (dirty: 0, valid: 1)
RIGHT:
(0) r0 (/32): 0x00E8 (dirty: 1, valid: 1)
(1) r1
Re: [Openocd-development] Strange problem with LPC2103
Small clarification: Everything is fine when I fun the chip ALONE - OpenOCD is closed, JTAG can be connected and powered, I cycle the power, everything works fine When I run OpenOCD and via telnet issue the commands: reset JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ve r: 0x4) JTAG Tap/device matched halt target state: halted target halted in ARM state due to debug-request, current mode: User cpsr: 0x8010 pc: 0x0144 reg [...] (11) r11 (/32): 0x41FC (dirty: 0, valid: 1) [...] (13) r13_usr (/32): 0x41F0 (dirty: 0, valid: 1) Here verything works as expected, the registers are fine soft_reset_halt requesting target halt and executing a soft reset target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x80d3 pc: 0x resume halt target state: halted target halted in ARM state due to debug-request, current mode: User cpsr: 0x8010 pc: 0x0170 reg [...] (11) r11 (/32): 0x41F9 (dirty: 0, valid: 1) [...] (13) r13_usr (/32): 0x41EC (dirty: 0, valid: 1) Here everything is wrong and you see the registers are wrong 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale broken in R2495?
On Wed, Jul 8, 2009 at 7:37 PM, David Brownelldavi...@pacbell.net wrote: On Wednesday 08 July 2009, Michael Schwingen wrote: XScale (IXP42x) is broken I reported not that long ago that PXA 255 is broken too ... it doesn't seem to be able to detect the chip in the JTAG chain. It's not clear to me if that was a *regression* since the 0.1.0 release though. It may have been years since it worked. Xscale worked until quite recently. I've got a pxa255 in my office that I could try to breathe some life into. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix flash programming w/aduc702x
On Wed, Jul 8, 2009 at 5:53 PM, Thomas A. Moultont...@moulton.us wrote: On Wed, 2009-07-08 at 17:31 +0200, Øyvind Harboe wrote: On Wed, Jul 8, 2009 at 5:20 PM, Thomas A. Moultont...@moulton.us wrote: On Wed, 2009-07-08 at 16:10 +0200, Øyvind Harboe wrote: This patch fixes the broken flash programming w/workarea enabled. Please test report. These bugs explain the intermittent SEGFAULT's reported + that flash programming worked some of the time. Pardon my ignorance, but is there an easy way to automatically apply this patch? patch -p0 /cygdrive/c/temp/fixaduc702xflash.txt NB! Note that without this fix you'll get *intermittant* crashes and flashing *could* work in some cases. Excellent! It works fine! Committed. Thanks for testing! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2471 - trunk/src/jtag
On 7/8/09 8:18 AM, Spencer Oliver s...@spen-soft.co.uk wrote: You asked me what the result of Spencer's patch was under Mac OS X. I tested it against my system this evening and as you will see below, it caused a number of startup faults. It also appears to make the j-link dongle completely unresponsive thereafter. I guess the bigger question is this. Did the Windows version ever suffer from the intermittent startup problem or was this exclusively a problem with Linux/Mac systems? If Windows doesn't need the usb_reset and doesn't suffer from the intermittent issue, doesn't it make more sense to put a conditional around it that excludes that step for windows rather then forcing the device search again? Info : J-Link initialization started / target CPU reset initiated Error: J-Link command 0xde failed (-13) Error: J-Link command 0xdc failed (-13) Error: J-Link command 0x01 failed (-13) Error: J-Link command EMU_CMD_VERSION failed (-13) Info : J-Link JTAG Interface ready Error: J-Link command 0xdd failed (-13) Error: J-Link command 0xdf failed (-13) Error: J-Link setting speed failed (-13) Error: usb_bulk_write failed (requested=6, result=-13) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: usb_bulk_write failed (requested=6, result=-13) Error: jlink_tap_execute, wrong result -107 (expected 1) . . . Strange, i fail to see why my patch would cause this. I have only tested the patch on linux and win32 and it works fine on these. All the patch does is re-enumerate after the usb_reset. Could you step through and see that a valid handle is returned? Cheers Spen Hi Spencer, The problem for Mac OS X starts when the second usb_open call is made after re-enumeration. Based on my testing the second call returns a valid handle. Unlike the first handle, however, it is a zombie since anything using it ends up in a permanent black hole. If I comment out that single line, your patch works OK. The problem is I am guessing that statement is critical to Windows operation or you would not have likely put it in there. I am trying some other things, to see if I can find a solution that works across all three platforms. What a pesky problem. Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] XScale broken in R2495?
Zach Welch wrote: On Wed, 2009-07-08 at 12:47 +0200, Øyvind Harboe wrote: How is the attached patch? The NEWS file details the migration of the installed scripts from $(pkglibdir) to $(pkgdatadir)/scripts; the former should not be used anymore, and custom scripts migrated into $(pkgdatadir)/site/. This patch will prevent us from forcing this migration, as the old location will continue to be be used. So it might fix the bug, but it seems bad. However, this particular example shows how our searching for files may be insufficient. Presently, there is no way to enforce a separation between script files and executable files (if such is desired). The effect of this would be to allow a site to install read-only binary files that may be used by read-write scripts. In reality, I think ACLs make this proposition more meaningful, but others can comment on the concept of privilege separation. Am I taking that idea too far here? I do not see *that* as a problem, but I think binaries like the debug handler (or other modules/plugins/...) that are a fixed component of the installed OpenOCD version should only be loaded from $(pkglibdir): there is no use in looking for them in the user's scripts directory, and if a file with the right name but wrong contents is found there, it will even disturb operation. In this light, I would rather see us add a mechanism to find the two types of file, such that the search paths for each are separated. Script files can be searched using one list of paths, and binary files from another. Internally, it seems like we could switch search paths based on the filename extension being loaded. Agreed, although I think the code that is looking for a file should specify the type of file, instead of relying on the extension. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2499 - trunk/src/flash
You need to re-post patches when they change substantially. You added
new code that was not in the original patch.
It still has whitespace problems.
On Wed, 2009-07-08 at 20:29 +0200, ohar...@mail.berlios.de wrote:
Author: oharboe
Date: 2009-07-08 20:29:03 +0200 (Wed, 08 Jul 2009)
New Revision: 2499
Modified:
trunk/src/flash/aduc702x.c
Log:
Fix SEGFAULTs and broken error handling for flash programming w/working area
Modified: trunk/src/flash/aduc702x.c
===
--- trunk/src/flash/aduc702x.c2009-07-08 10:38:50 UTC (rev 2498)
+++ trunk/src/flash/aduc702x.c2009-07-08 18:29:03 UTC (rev 2499)
@@ -193,6 +193,11 @@
return ERROR_FLASH_OPERATION_FAILED;
}
+/* If this fn returns ERROR_TARGET_RESOURCE_NOT_AVAILABLE, then the caller
can fall
+ * back to another mechanism that does not require onboard RAM
+ *
+ * Caller should not check for other return values specifically
+ */
static int aduc702x_write_block(struct flash_bank_s *bank, uint8_t *buffer,
uint32_t offset, uint32_t count)
{
aduc702x_flash_bank_t *aduc702x_info = bank-driver_priv;
@@ -204,6 +209,12 @@
armv4_5_algorithm_t armv4_5_info;
int retval = ERROR_OK;
+ if (((count%2)!=0)||((offset%2)!=0))
+ {
+ LOG_ERROR(write block must be multiple of two bytes in offset
length);
+ return ERROR_FAIL;
+ }
+
/* parameters:
r0 - address of source data (absolute)
@@ -249,8 +260,12 @@
return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
};
- target_write_buffer(target, aduc702x_info-write_algorithm-address,
+ retval=target_write_buffer(target,
aduc702x_info-write_algorithm-address,
sizeof(aduc702x_flash_write_code),
(uint8_t*)aduc702x_flash_write_code);
+ if (retval!=ERROR_OK)
+ {
+ return retval;
+ }
/* memory buffer */
while (target_alloc_working_area(target, buffer_size, source) !=
ERROR_OK)
@@ -279,12 +294,16 @@
while (count 0)
{
- uint32_t thisrun_count = (count (buffer_size / 2)) ?
(buffer_size / 2) : count;
+ uint32_t thisrun_count = (count buffer_size) ? buffer_size :
count;
- target_write_buffer(target, source-address, thisrun_count * 2,
buffer);
+ retval=target_write_buffer(target, source-address,
thisrun_count, buffer);
+ if (retval!=ERROR_OK)
+ {
+ break;
+ }
buf_set_u32(reg_params[0].value, 0, 32, source-address);
- buf_set_u32(reg_params[1].value, 0, 32, thisrun_count);
+ buf_set_u32(reg_params[1].value, 0, 32, thisrun_count/2);
buf_set_u32(reg_params[2].value, 0, 32, address);
buf_set_u32(reg_params[4].value, 0, 32, 0xF800);
@@ -294,17 +313,19 @@
1, armv4_5_info)) != ERROR_OK)
{
LOG_ERROR(error executing aduc702x flash write
algorithm);
- retval = ERROR_FLASH_OPERATION_FAILED;
break;
}
- if ((buf_get_u32(reg_params[3].value, 0, 32) 1) != 1) {
- retval = ERROR_FLASH_OPERATION_FAILED;
+ if ((buf_get_u32(reg_params[3].value, 0, 32) 1) != 1)
+ {
+ /* FIX what does this mean??? replace w/sensible
error message */
+ LOG_ERROR(aduc702x detected error writing flash);
+ retval = ERROR_FAIL;
break;
}
- buffer += thisrun_count * 2;
- address += thisrun_count * 2;
+ buffer += thisrun_count;
+ address += thisrun_count;
count -= thisrun_count;
}
@@ -382,14 +403,9 @@
return ERROR_FLASH_OPERATION_FAILED;
}
}
-else if (retval == ERROR_FLASH_OPERATION_FAILED)
-{
-LOG_ERROR(flash block writing failed);
-return ERROR_FLASH_OPERATION_FAILED;
-}
}
-return ERROR_OK;
+return retval;
}
static int aduc702x_probe(struct flash_bank_s *bank)
___
Openocd-svn mailing list
openocd-...@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-svn
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix xscale debug_handler.bin take #2
On Wed, 2009-07-08 at 16:25 +0200, Øyvind Harboe wrote: Testingcomments appreciated! I'm thinking that target executables should be placed into the same folder as scripts. It's not really executables from the host OS's point of view, it's just data that ships w/OpenOCD and that OpenOCD uses. If you are going to relocate the installed files, do NOT add PKGDATADIR to the script search path. Install the files into the existing PKGDATADIR/scripts tree or in a new subdirectory. The current patch would make a serious mess of the installation. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2499 - trunk/src/flash
I just saw you did re-post... but you only waited 4 hours. That is not
enough time. You need to wait 12-24 hours, preferably 24.
On Wed, 2009-07-08 at 13:50 -0700, Zach Welch wrote:
You need to re-post patches when they change substantially. You added
new code that was not in the original patch.
It still has whitespace problems.
On Wed, 2009-07-08 at 20:29 +0200, ohar...@mail.berlios.de wrote:
Author: oharboe
Date: 2009-07-08 20:29:03 +0200 (Wed, 08 Jul 2009)
New Revision: 2499
Modified:
trunk/src/flash/aduc702x.c
Log:
Fix SEGFAULTs and broken error handling for flash programming w/working area
Modified: trunk/src/flash/aduc702x.c
===
--- trunk/src/flash/aduc702x.c 2009-07-08 10:38:50 UTC (rev 2498)
+++ trunk/src/flash/aduc702x.c 2009-07-08 18:29:03 UTC (rev 2499)
@@ -193,6 +193,11 @@
return ERROR_FLASH_OPERATION_FAILED;
}
+/* If this fn returns ERROR_TARGET_RESOURCE_NOT_AVAILABLE, then the caller
can fall
+ * back to another mechanism that does not require onboard RAM
+ *
+ * Caller should not check for other return values specifically
+ */
static int aduc702x_write_block(struct flash_bank_s *bank, uint8_t
*buffer, uint32_t offset, uint32_t count)
{
aduc702x_flash_bank_t *aduc702x_info = bank-driver_priv;
@@ -204,6 +209,12 @@
armv4_5_algorithm_t armv4_5_info;
int retval = ERROR_OK;
+ if (((count%2)!=0)||((offset%2)!=0))
+ {
+ LOG_ERROR(write block must be multiple of two bytes in offset
length);
+ return ERROR_FAIL;
+ }
+
/* parameters:
r0 - address of source data (absolute)
@@ -249,8 +260,12 @@
return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
};
- target_write_buffer(target, aduc702x_info-write_algorithm-address,
+ retval=target_write_buffer(target,
aduc702x_info-write_algorithm-address,
sizeof(aduc702x_flash_write_code),
(uint8_t*)aduc702x_flash_write_code);
+ if (retval!=ERROR_OK)
+ {
+ return retval;
+ }
/* memory buffer */
while (target_alloc_working_area(target, buffer_size, source) !=
ERROR_OK)
@@ -279,12 +294,16 @@
while (count 0)
{
- uint32_t thisrun_count = (count (buffer_size / 2)) ?
(buffer_size / 2) : count;
+ uint32_t thisrun_count = (count buffer_size) ? buffer_size :
count;
- target_write_buffer(target, source-address, thisrun_count * 2,
buffer);
+ retval=target_write_buffer(target, source-address,
thisrun_count, buffer);
+ if (retval!=ERROR_OK)
+ {
+ break;
+ }
buf_set_u32(reg_params[0].value, 0, 32, source-address);
- buf_set_u32(reg_params[1].value, 0, 32, thisrun_count);
+ buf_set_u32(reg_params[1].value, 0, 32, thisrun_count/2);
buf_set_u32(reg_params[2].value, 0, 32, address);
buf_set_u32(reg_params[4].value, 0, 32, 0xF800);
@@ -294,17 +313,19 @@
1, armv4_5_info)) != ERROR_OK)
{
LOG_ERROR(error executing aduc702x flash write
algorithm);
- retval = ERROR_FLASH_OPERATION_FAILED;
break;
}
- if ((buf_get_u32(reg_params[3].value, 0, 32) 1) != 1) {
- retval = ERROR_FLASH_OPERATION_FAILED;
+ if ((buf_get_u32(reg_params[3].value, 0, 32) 1) != 1)
+ {
+ /* FIX what does this mean??? replace w/sensible
error message */
+ LOG_ERROR(aduc702x detected error writing flash);
+ retval = ERROR_FAIL;
break;
}
- buffer += thisrun_count * 2;
- address += thisrun_count * 2;
+ buffer += thisrun_count;
+ address += thisrun_count;
count -= thisrun_count;
}
@@ -382,14 +403,9 @@
return ERROR_FLASH_OPERATION_FAILED;
}
}
-else if (retval == ERROR_FLASH_OPERATION_FAILED)
-{
-LOG_ERROR(flash block writing failed);
-return ERROR_FLASH_OPERATION_FAILED;
-}
}
-return ERROR_OK;
+return retval;
}
static int aduc702x_probe(struct flash_bank_s *bank)
___
Openocd-svn mailing list
openocd-...@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-svn
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
Re: [Openocd-development] [Openocd-svn] r2499 - trunk/src/flash
On Wed, Jul 8, 2009 at 11:00 PM, Zach Welchz...@superlucidity.net wrote: I just saw you did re-post... but you only waited 4 hours. That is not enough time. You need to wait 12-24 hours, preferably 24. 24h it is until 0.2 is out then. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix xscale debug_handler.bin take #2
On Wed, Jul 8, 2009 at 10:56 PM, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-07-08 at 16:25 +0200, Øyvind Harboe wrote: Testingcomments appreciated! I'm thinking that target executables should be placed into the same folder as scripts. It's not really executables from the host OS's point of view, it's just data that ships w/OpenOCD and that OpenOCD uses. If you are going to relocate the installed files, do NOT add PKGDATADIR to the script search path. Install the files into the existing PKGDATADIR/scripts tree or in a new subdirectory. The current patch would make a serious mess of the installation. I wanted to use a new subdirectory for all these target binaries, but I don't speak automake well enough to pull it off. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix xscale debug_handler.bin take #2
On Wed, 2009-07-08 at 23:09 +0200, Øyvind Harboe wrote: On Wed, Jul 8, 2009 at 10:56 PM, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-07-08 at 16:25 +0200, Øyvind Harboe wrote: Testingcomments appreciated! I'm thinking that target executables should be placed into the same folder as scripts. It's not really executables from the host OS's point of view, it's just data that ships w/OpenOCD and that OpenOCD uses. If you are going to relocate the installed files, do NOT add PKGDATADIR to the script search path. Install the files into the existing PKGDATADIR/scripts tree or in a new subdirectory. The current patch would make a serious mess of the installation. I wanted to use a new subdirectory for all these target binaries, but I don't speak automake well enough to pull it off. Yeah, that's a little trickier. I still think these files need to be in pkglibdir, though. I think moving them to the pkgdatadir will cause warnings on some packaging systems (e.g. Fedora RPM, IIRC). --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/5] Add comments to top-level files to excuse their Doxygen markup.
David Brownell escreveu: On Wednesday 08 July 2009, Xiaofan Chen wrote: Is this a la Jim English? Is it aka Jim? or also know as Jim? I am not a native speaker of English though. It's a borrowing from French, where a la would be kind of odd. Best change to , as done with Jim? That's french all right. It is a short for à la mode de Jim. In english it would be Jim's way Alain ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Version 3 test patch for jlink.c
Zach/Spencer/Xiaofan, I did some more experimentation on the latest subversion (2499) and was able to tweak the jlink.c code slightly to possibly achieve three objectives: 1. Make jlink dongles work under Windows for Spencer. 2. Make jlink dongles work under Mac OS X for me. 3. Make jlink dongles work under Linux for Zach and Xiaofan. 4. Note the possible future problem that Xiaofan uncovered with libusb interactions in the Linux kernel and use it in such a way that the code in jlink.c won't cause future problems. I have confirmed #2 and believe that #4 is satisfied. What I don't know is whether #1 and #4 are. Could you try this out with your dongles and let me know what happens? If the patch works, I need to do a little cleanup but I didn't want to focus on that until I knew for sure whether it would solve the issues at hand. Thanks, Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. jlink_v3_patch.txt Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] libusb-win32 svn released as 0.1.12.2
On Thu, Jul 9, 2009 at 12:19 AM, Michael Fischerfische...@t-online.de wrote: Hello Xiaofan, I have updated the Sparkfun page now, please check it. Thanks. It is quite good now. PS: The best is if the OpenOCD project get a wiki page, where other one can add information too? I agree. -- 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] Version 3 test patch for jlink.c
On Thu, Jul 9, 2009 at 5:53 AM, Gary Carlsongcarl...@carlson-minot.com wrote:
Zach/Spencer/Xiaofan,
I did some more experimentation on the latest subversion (2499) and was able
to tweak the jlink.c code slightly to possibly achieve three objectives:
1. Make jlink dongles work under Windows for Spencer.
2. Make jlink dongles work under Mac OS X for me.
3. Make jlink dongles work under Linux for Zach and Xiaofan.
4. Note the possible future problem that Xiaofan uncovered with libusb
interactions in the Linux kernel and use it in such a way that the code in
jlink.c won't cause future problems.
I have confirmed #2 and believe that #4 is satisfied. What I don't know is
whether #1 and #4 are. Could you try this out with your dongles and let me
know what happens?
If the patch works, I need to do a little cleanup but I didn't want to focus
on that until I knew for sure whether it would solve the issues at hand.
I will test this patch this evening.
What I am thinking now is that this patch is still strange. Typically
the usb_set_configuration() will solve some problems for some USB
device (say USB toggle bit problems) since it is also a light weight
reset.
But in case usb_reset() is necessary, it is typically called during the
closing stage.
An example I wrote before.
http://www.microchip.com/forums/tm.aspx?m=340892
That is to say, typically you call these three instruction
when closing the usb_handle (after you finish the operation and
prepare for exit).
usb_release_interface(devh, 0);
usb_rese(devh); //adding this line makes the program happy
usb_close(devh);
Which means in this case:
static void jlink_usb_close(jlink_jtag_t *jlink_jtag)
{
usb_close(jlink_jtag-usb_handle);
free(jlink_jtag);
}
becomes
static void jlink_usb_close(jlink_jtag_t *jlink_jtag)
{
usb_release_interface((jlink_jtag-usb_handle,0);
usb_reset(jlink_jtag-usb_handle);
usb_close(jlink_jtag-usb_handle);
free(jlink_jtag);
}
Could you try this?
Personally I observed that normally first launch of OpenOCD is okay
and the subsequent launch of OpenOCD might cause startup problems.
So this indicates that the exit may not be so clean and this leads to
Jlink's initial status in a undesired state which even usb_set_configuration
can not help.
But if you see the problems even during the first launch, then the above
may not help.
--
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 0/5] Documentation Updates for 0.2.0
On Thu, Jul 9, 2009 at 1:24 AM, David Brownelldavi...@pacbell.net wrote: On Wednesday 08 July 2009, Zach Welch wrote: The files in this series are meant for review, so feedback may be incorporated in them before I commit them. 1/5 Add comments to top-level files to excuse their Doxygen markup. 2/5 Add microscopic style guide at the end of the PATCH primer. 3/5 Add section to provide some documentation for cross-compiling. 4/5 Add style rule to avoid combining assignment and logical tests. 5/5 Document Maintainers and Testing. I'll ACK #s 1-4. #5 seems like two significant patches combined into one, and they seem like they each need more review ... If I were a maintainer (luckily or unluckily I am not), I would be a bit scared by the harsh/strict words in the Maintainers document considering the fact that all the maintainers and active contributors spend their free time to do free development... As for the test document part, I feel this sentence is a bit strange. Users should never be asked to test the SVN.. Maybe this sentence itself is correct. But users will have to test the SVN after all since OpenOCD has not reached 1.0 stage and many bug fixes will have to be tested in SVN. -- 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] Version 3 test patch for jlink.c
On 7/8/09 5:05 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Thu, Jul 9, 2009 at 5:53 AM, Gary Carlsongcarl...@carlson-minot.com
wrote:
Zach/Spencer/Xiaofan,
I did some more experimentation on the latest subversion (2499) and was able
to tweak the jlink.c code slightly to possibly achieve three objectives:
1. Make jlink dongles work under Windows for Spencer.
2. Make jlink dongles work under Mac OS X for me.
3. Make jlink dongles work under Linux for Zach and Xiaofan.
4. Note the possible future problem that Xiaofan uncovered with libusb
interactions in the Linux kernel and use it in such a way that the code in
jlink.c won't cause future problems.
I have confirmed #2 and believe that #4 is satisfied. What I don't know is
whether #1 and #4 are. Could you try this out with your dongles and let me
know what happens?
If the patch works, I need to do a little cleanup but I didn't want to focus
on that until I knew for sure whether it would solve the issues at hand.
I will test this patch this evening.
What I am thinking now is that this patch is still strange. Typically
the usb_set_configuration() will solve some problems for some USB
device (say USB toggle bit problems) since it is also a light weight
reset.
But in case usb_reset() is necessary, it is typically called during the
closing stage.
An example I wrote before.
http://www.microchip.com/forums/tm.aspx?m=340892
That is to say, typically you call these three instruction
when closing the usb_handle (after you finish the operation and
prepare for exit).
usb_release_interface(devh, 0);
usb_rese(devh); //adding this line makes the program happy
usb_close(devh);
Which means in this case:
static void jlink_usb_close(jlink_jtag_t *jlink_jtag)
{
usb_close(jlink_jtag-usb_handle);
free(jlink_jtag);
}
becomes
static void jlink_usb_close(jlink_jtag_t *jlink_jtag)
{
usb_release_interface((jlink_jtag-usb_handle,0);
usb_reset(jlink_jtag-usb_handle);
usb_close(jlink_jtag-usb_handle);
free(jlink_jtag);
}
Could you try this?
Personally I observed that normally first launch of OpenOCD is okay
and the subsequent launch of OpenOCD might cause startup problems.
So this indicates that the exit may not be so clean and this leads to
Jlink's initial status in a undesired state which even usb_set_configuration
can not help.
But if you see the problems even during the first launch, then the above
may not help.
According the the libusb manual your use syntax is right. However, I get
the feeling that the manual makes a deadly assumption that every software
program that uses a USB port cleans it up properly at the end. I ran one
experiment a few days ago alternating between a USB mouse and the J-link
dongle and it caused a 100% startup failure rate in the J-link software.
I am obviously assuming that cleanup is a problem, but I will make the
concession that this is conjecture on my part without doing further
research.
I do agree with you though that if the intent is to follow the libusb manual
we should do a reset at the end in the jlink code.
If the test patch works for everyone, I can throw that in if everyone
agrees.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] lm3s3748 cleanup
Update lm3s3748 support: split EK board support out
from the target CPU support ... other boards with this
chip will likely be set up differently.
Shrink some too-long lines in that target CPU support.
---
tcl/board/ek-lm3s3748.cfg | 17 +
tcl/target/lm3s3748.cfg | 35 +++
2 files changed, 28 insertions(+), 24 deletions(-)
Update lm3s3748 support: split EK board support out
from the target CPU support ... other boards with this
chip will likely be set up differently.
Shrink some too-long lines in that target CPU support.
---
tcl/board/ek-lm3s3748.cfg | 17 +
tcl/target/lm3s3748.cfg | 35 +++
2 files changed, 28 insertions(+), 24 deletions(-)
--- /dev/null
+++ b/tcl/board/ek-lm3s3748.cfg
@@ -0,0 +1,17 @@
+# Stellaris lm3s3748 Evaluation Kit
+# http://www.luminarymicro.com/products/lm3s3748_usb_h_d_evaluation_kits.html
+
+# NOTE: to use the on-board FT2232 JTAG interface:
+# source [find interface/luminary.cfg]
+
+source [find target/lm3s3748.cfg]
+
+# LM3S parts don't support RTCK
+jtag_khz 500
+
+jtag_nsrst_delay 100
+jtag_ntrst_delay 100
+
+# Board has only srst
+reset_config srst_only
+
--- a/tcl/target/lm3s3748.cfg
+++ b/tcl/target/lm3s3748.cfg
@@ -1,7 +1,4 @@
-# Script for luminary lm3s3748
-#
-# NB! work in progress! Duplicated from lm3s811.cfg, but does
-# it need modification??
+# TI/Luminary Stellaris lm3s3748
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
@@ -19,31 +16,21 @@ if { [info exists ENDIAN] } {
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
- # force an error till we get a good number
set _CPUTAPID 0x3ba00477
}
-# RCLK
-jtag_khz 500
-
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
-
-#lm3s3748 Evaluation Board has only srst
-reset_config srst_only
-
-#jtag scan chain
+# JTAG scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0xf -expected-id $_CPUTAPID
+# The lm3s variant works around an erratum when using Rev A of DustDevil
+# parts (third generation, includes LM3S3748). It keeps the debug registers
+# from being cleared, by using software reset not SRST; NOP on newer revs.
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME cortex_m3 -endian $_ENDIAN \
+ -chain-position $_TARGETNAME -variant lm3s
-# the luminary variant causes a software reset rather than asserting SRST
-# this stops the debug registers from being cleared
-# this will be fixed in later revisions of silicon
-set _TARGETNAME [format %s.cpu $_CHIPNAME]
-target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position $_TARGETNAME -variant lm3s
-
-# 8k working area at base of ram
-$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x2000 -work-area-size 0x2000 -work-area-backup 0
+# 8k working area at base of ram, not backed up
+$_TARGETNAME configure -work-area-phys 0x2000 -work-area-size 0x2000
-#flash configuration
+# flash configuration -- one bank of 128K
flash bank stellaris 0 0 0 0 0
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/5] Documentation Updates for 0.2.0
On Wednesday 08 July 2009, Xiaofan Chen wrote: If I were a maintainer (luckily or unluckily I am not), I would be a bit scared by the harsh/strict words in the Maintainers document considering the fact that all the maintainers and active contributors spend their free time to do free development... Yeah, it did look like it was demanding/expecting a bit much. As for the test document part, I feel this sentence is a bit strange. Users should never be asked to test the SVN.. Maybe this sentence itself is correct. But users will have to test the SVN after all since OpenOCD has not reached 1.0 stage and many bug fixes will have to be tested in SVN. I didn't see that part. It seems incorrect. There's no better way to establish the bug is *fixed* than testing SVN. So the never is incorrect. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/5] Documentation Updates for 0.2.0
On Thu, 2009-07-09 at 09:56 +0800, Xiaofan Chen wrote: On Thu, Jul 9, 2009 at 1:24 AM, David Brownelldavi...@pacbell.net wrote: On Wednesday 08 July 2009, Zach Welch wrote: The files in this series are meant for review, so feedback may be incorporated in them before I commit them. 1/5 Add comments to top-level files to excuse their Doxygen markup. 2/5 Add microscopic style guide at the end of the PATCH primer. 3/5 Add section to provide some documentation for cross-compiling. 4/5 Add style rule to avoid combining assignment and logical tests. 5/5 Document Maintainers and Testing. I'll ACK #s 1-4. #5 seems like two significant patches combined into one, and they seem like they each need more review ... If I were a maintainer (luckily or unluckily I am not), I would be a bit scared by the harsh/strict words in the Maintainers document considering the fact that all the maintainers and active contributors spend their free time to do free development... Volunteers in most communities are expected to behave professionally, as evidenced by medical or early educational volunteer positions. If you do not perform according to expectations, you do not get to retain the privilege of even a volunteer position. That may sound harsh, but it derives from high standards. In this way, we need these guidelines to define the roles of key contributors, as performance standards can only be enforced from the top down. The reality about the harsh language is this: I hope it never needs to be used. However, you should read this as a social contract: governance of the project is in the maintainers hands, and this document spells out their responsibilities -- which allows users to hold us accountable. Without such language, there will be only continued chaos, which has led to valued contributors leaving the project and threats to fork the code. If the rules seem too harsh, then you are not ready to be a maintainer. This may itself sound harsh, but I hear the world is unfair too. These are drafts documents, however; I want to incorporate feedback like yours until the community agrees that the guidelines seem fair. The language may need to be revised for any number of reasons; however, these kinds of guidelines exist in any project that reaches a certain critical mass. With these guidelines in place and agreed upon, the community should be able resolve disputes regarding maintainer authority, responsibility, and accountability in the project. Personally, I have no problem being held accountable for the responsibilities that I have been doing here, so long as I had the required authority to complete the work. Speaking in the capacity of an unpaid volunteer, I will not continue to volunteer my time on a project that has been filled with volatility, most of which appear to be caused by power struggles over issues that could have been resolved if proper management had been in place. Wither paid or not, these are signs of a poorly governed project. These guidelines seek to put an end to such shenanigans, before the constant turmoil drives all of the quality contributors to create a fork where this chaos will never be allowed to blossom in the first place. As for the test document part, I feel this sentence is a bit strange. Users should never be asked to test the SVN.. Maybe this sentence itself is correct. But users will have to test the SVN after all since OpenOCD has not reached 1.0 stage and many bug fixes will have to be tested in SVN. There is an important point to make to start: the labels user and developer are disgustingly black-and-white for open source software. Our reality tends to be full of gray; however, I think it is clearly a bad policy to ask users -- those who are not developers -- to use the developer SVN repository. We should be producing releases frequently enough that users can wait for the next release. If you _can_ build the repository, then you are not really a user in this scenario. I do _not_ want users trying to _build_ the SVN repository. Asking the users to test the SVN is asking them to do everything that a developer must do. That is an unacceptable process for users, as it will result in more false reports from failed (re)building than it will help test the bug. Instead, they should wait for a source archive release, which will not require them to use the autotools bootstrap. If we need users to test more often than releases, we can produce nightly tarballs. They should _not_ use SVN. Our processes have failed if we must ask them to do so. In other words, the costs of users trying to use SVN will far outweigh the benefits , when nightly tarballs would solve the problem. Further, most users will probably be running binaries provided by others, and those individuals should be reporting bugs to their distributor -- not the open source community. Those individuals _can_ test SVN. Cheers, Zach
Re: [Openocd-development] Fix xscale debug_handler.bin take #2
On Wed, 2009-07-08 at 23:37 +0200, Øyvind Harboe wrote: I wanted to use a new subdirectory for all these target binaries, but I don't speak automake well enough to pull it off. Yeah, that's a little trickier. I still think these files need to be in pkglibdir, though. I think moving them to the pkgdatadir will cause warnings on some packaging systems (e.g. Fedora RPM, IIRC). OK. That's it. You scared me away from this one :-) For 0.2 there is a workaround by adding a search dir on the command line. I'm not going to attempt a fix. I think this is safest for now, until we figure out the right solution. It appears that a couple of others have a vague interest in keeping these file trees separated, but we lack an acceptable workaround that does not suffer from some other problems. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2499 - trunk/src/flash
On Wed, 2009-07-08 at 23:08 +0200, Øyvind Harboe wrote: On Wed, Jul 8, 2009 at 11:00 PM, Zach Welchz...@superlucidity.net wrote: I just saw you did re-post... but you only waited 4 hours. That is not enough time. You need to wait 12-24 hours, preferably 24. 24h it is until 0.2 is out then. Let me try to clarify a little. For code, 24 hours is good. For docs, 12 hours probably is enough (particularly after a full ACK). That is long enough for everyone to revisit the list. Some patch churn in the docs does not seem as blasphemous to me as patch churn in the code, for some reason. Anyone care to try and explain that bit of reasoning? :) I suppose it may be from the fact that clean patching of documentation seems difficult beyond its value; I often can't grok the patch alone, so I have to apply it to review. Clean patching of code is easier (when it has a good style), and they can be easier to review without applying. Is that rational, or rationalization? ;) Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
