Re: [Openocd-development] Mailing list?
On 17 December 2011 16:49, Freddie Chopin freddie_cho...@op.pl wrote: Hi! From what I've read berlios has found some funding so it's going to operate, but will the mailing lists be kept online? Sourceforge deleted the list, there is an archive available, so what's so hard in undeleting it? I wish i could answer but we are still waiting for sf to fix the issue. The original sf ticket is here, feel free to bombard sf until they sort it out: https://sourceforge.net/apps/trac/sourceforge/ticket/22906 So far i have tried the trac ticket, irc and email - i have been promised that the priority has been raised - and then nothing. I am also trying to get an email for the support manager to complain as i believe this is not acceptable - the mailing list is the main communication channel for OpenOCD. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JimTCL and Fedora RPMs
On 15 December 2011 05:44, Dean Glazeski dngl...@gmail.com wrote:
Hey guys,
Long time no see. Recently, I got a bug request through Red Hat bugs to
package the newer version of OpenOCD for Fedora. It's been a while, but it
finally kicked me in gear to take care of it (seeing as 0.5.0 was released
quite a while ago).
As I was working on the package, I noticed some issues with the compiler and
tools detection in JimTCL. Most importantly, it doesn't check for just the
tool name, ie 'ld', if host and/or build are set in the configure line. In
my case, rpmbuild likes to set these options, but it isn't really a cross
compile job (although it may be once I request a build in Fedora's systems).
At any rate, I've attached the patch (perhaps kludge) that I'm using in the
build to make JimTCL build properly. I'm going to hold the RPM until I get
word from you guys about whether this is a bug or if I should be posting
this to another mailing list.
Also, rpmlint picked up that the FSF address in your COPYING file is
incorrect. Patch attached as well.
// Dean Glazeski
Thanks,
The jimtcl tweaks i will forward onto Steve for comment.
Cheers
Spen
--- jimtcl/autosetup/cc.tcl.bak 2011-12-14 20:54:36.612369362 -0600
+++ jimtcl/autosetup/cc.tcl 2011-12-14 21:15:43.173535171 -0600
@@ -240,7 +240,10 @@
set TOOL [string toupper $tool]
set exe [get-env $TOOL [get-define cross]$tool]
if {![find-executable $exe]} {
- user-error Failed to find $exe
+set exe $tool
+if {![find-executable $exe]} {
+ user-error Failed to find $exe
+}
}
define $TOOL $exe
}
@@ -620,7 +623,7 @@
set try [list [get-env CC ]]
} else {
# Try some reasonable options
- set try [list [get-define cross]cc [get-define cross]gcc]
+ set try [list [get-define cross]cc [get-define cross]gcc cc gcc]
}
define CC [find-an-executable {*}$try]
if {[get-define CC] eq } {
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: Delivery Status Notification (Failure)
On 15 December 2011 15:15, Akos Vandra axo...@gmail.com wrote: -- Forwarded message -- From: Mail Delivery Subsystem mailer-dae...@googlemail.com Date: 15 December 2011 16:14 Subject: Delivery Status Notification (Failure) To: axo...@gmail.com Delivery to the following recipient failed permanently: openocd-de...@lists.sourceforge.net Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 unknown user (state 14). Yes we have some issues with the sf mailing lists at the moment - hopefully they will be fixed soon. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Google presentation on OpenOCD Gerrit experience
On 2 December 2011 14:12, Laurent Gauch laurent.ga...@amontec.com wrote: What do you mean by Senior developers ? Developers bestowes us with their great acumen. What do you really interpret At the sharp rise, Gerrit was introduced ? # of commits rose from 3 to 30 a week. I am really not sure to find any correlation between the coming of gerrit and the number of new commits ! Also 90% of the last new commits were whitespace diffs ! In the last 50 commits - i see 1 whitespace cleanup. http://openocd.zylin.com/#q,status:merged,n,z I will try harder :-) Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Google presentation on OpenOCD Gerrit experience
On 24 November 2011 08:28, Øyvind Harboe oyvind.har...@zylin.com wrote: Comments welcome! https://docs.google.com/present/view?id=dhftn35p_14s2xxcbt3 It was a good read during my lunch :-) Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 16 November 2011 23:05, Whitlock, Bradley D bradley.d.whitl...@lmco.com wrote: I believe I have found the issue with one of the previous issues that I do not believe has been solved yet (see below): I thought the issue was resolved - it is for me anyway. Are you building from git master or a release ? Replied to new mailing list aswell - the old one will be closing soon - 31/12/2011 Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] mailing lists
Hi, I have been waiting quite a while for sf to move the mailing list archives/users - it is now done :) Everybody that was subscribed to the old lists should be moved over to the ones at sf. This msg has been sent to both lists so that people can check the list settings have moved over correctly. https://lists.sourceforge.net/lists/listinfo/openocd-devel https://lists.sourceforge.net/lists/listinfo/openocd-commit So update your spam filters etc and use new list asap For info all commit/gerrit messages will now use the new list. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] include linux/scripts in OpenOCD project?
On 2 November 2011 20:03, Øyvind Harboe oyvind.har...@zylin.com wrote: Should we? i guess it makes sense, i will sort out and add a tools/scripts dir. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] scan-build and gerrit rant
if we start tweaking perfectly good code and adding nonsense checks just to get a clean scan-build output, I think that's a step backwards in terms of code quality. Yes, I agree. I'm not at all fond of throwing assert() at the clang warnings. +1 from me aswell. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] checkpatch enabled
Hi, All patches submitted to gerrit will be verified using checkpatch. Also just to give you insight on the jenkins setup: http://openocd.zylin.com/jenkins/ we have a few jobs configured: openocd - built whenever master branch changes. openocd-gerrit - run whenever a change is sent to gerrit - also runs checkpatch against change. openocd-clang - runs clang whenever openocd job changes openocd-build - runs various host builds whenever openocd job changes - currently linux32, mingw32 and mingw64 builds are checked. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Modify a git commit ?
On 28 October 2011 15:21, Jonathan Dumaresq jdumar...@cimeq.qc.ca wrote: HI, I have create a change in one of my patch that i have already sent. I commited it, but I forget to add the signed-off by... Is it possible to edit a commit message ? Jonathan git commit -s --amend Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clang warnings
On 27/10/2011 18:30, Øyvind Harboe wrote: Hi, Spencer has gotten clang up and running again on the server! :-) Please take a moment to fix a warning or two that you can find in the latest warning list for clang builds. You'll notice that there is a nice graph that we can use to track our progress in terms of warnings. When reviewing, I'd like us not to increase # of warnings with new patches, but that check is not enforced yet via Gerrit verification flag. http://openocd.zylin.com/jenkins/job/openocd-clang/2/warningsResult/ use this url and it will always take you to the latest warnings: http://openocd.zylin.com/jenkins/job/openocd-clang/lastBuild/warningsResult/? just for info we can also see the scan-build output if you prefer: http://openocd.zylin.com/jenkins/job/openocd-clang/ws/scan-build/index.html Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gerrit comments as mail?
On 26 October 2011 13:35, Attila Kinali att...@kinali.ch wrote: Moin, Would it possible to have gerrit comments as mails to the mailinglist as well? This is down to taste - some would class lots of gerrit emails spam. My suggestion is to watch the openocd project in gerrit, enabling emails there: http://openocd.zylin.com/#settings,projects Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Can't push...
On 27/10/2011 00:10, jim norris wrote: I'm trying to do a 'git push review' and it just hangs. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development try now ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Can't push...
On 27/10/2011 00:13, jim norris wrote: try now Nope. Still hangs. working fine this end, so unsure what to suggest Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] adding checkpatch to code review on jenkins
On Oct 25, 2011 8:34 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Could someone take checkpatch for a spin and reporter back to the list on if/how we should use in w/Gerrit+Jenkins review? I think it is used client side. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] commit - jim-nvp is moving from jimtcl to openocd
with ref to subject commit ef885d3b2a3001325f525df250dadd570e5d743e the files jim-nvp.[ch] have no copyright info. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
On 20 October 2011 17:04, Freddie Chopin freddie_cho...@op.pl wrote: Hi! The most recent OpenOCD behaves differently on Windows than 0.5.0 (and before) and in my opinion the direction of change is to worse. OpenOCD 0.5.0 could be run this way: openocd -f interface/jtagkey.cfg -f target/stm32.cfg And it worked fine. Current OpenOCD when trying this gives: Runtime Error: embedded:startup.tcl:58: couldn't read file D:openocd-devopenocd -0.6.0-dev-11102001452in../interface/jtagkey.cfg: No such file or directory in procedure 'script' at file embedded:startup.tcl, line 58 The only working version that I've found is: openocd -f ../interface/jtagkey.cfg -f ../target/stm32.cfg i cannot reproduce this problem, any more details. But that's not all. Other differences: 1. In 0.5.0 you could use slash or backslash (which is more correct in Windows) - no difference. Now only slash works, backslash is ommited and replaced with... nothing... 2. When running OpenOCD as External Tool from Eclipse I always left Working Dir empty and it worked fine, now I have to specify this directory for OpenOCD to work - probably because backslashes in Windows paths are replaced with nothing... I think that the root cause for the problem is because backslashes are now treated differently. Can that be fixed? Is that a problem of OpenOCD or JimTCL or maybe you don't consider this a problem at all? double backslash seems to fix it. However i always use forward slash so its not an issue for me. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
On 21 October 2011 12:40, freddie_chopin freddie_cho...@op.pl wrote: W dniu 2011-10-21 13:06:05 użytkownik Spencer Oliver s...@spen-soft.co.uk napisał: i cannot reproduce this problem, any more details. We'll... I've compiled master from yesterday, using the same tools and libraries (libusb and libftdi) as before, using the same script as before - generally nothing changed from my point of view but I cannot run OpenOCD as before - using -f target/whatever.cfg produces an error as in first post. I've checked on another PC now and it's the same: Runtime Error: embedded:startup.tcl:58: couldn't read file D:openocd-0.6.0-dev- 11102001452in../interface/jtagkey.cfg: No such file or directory The root cause is that backslashes from path are removed, so D:\openocd-0.6.0-dev-11102001452\ becomes D:openocd-0.6.0-dev-11102001452 which is worthless. Maybe there were some changes in jimtcl lately? As I said - 0.5.0 compiled 2 months ago works fine. Is there any way I could see which version of jimtcl OpenOCD uses and somehow force it to use some other to see whether that's a problem of OpenOCD or jimtcl? you could either do a git bisect to see what version it broke at. to use an external version of jim pass --disable-internal-jimtcl to configure Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gitweb down?
On 20 October 2011 11:49, Uwe Hermann u...@hermann-uwe.de wrote: Hi, seems like the gitweb for OpenOCD is down? E.g. the links such as http://openocd.zylin.com/gitweb/?p=openocd.git;a=commit;h=a756b1bcdffef34a6d60d7a2706da9574663f544 no longer work (they did yesterday). There are links from Gerrits pages to the gitweb install, for example (and that's a good thing; please don't drop gitweb, I for one find it very useful; the commitdiff view there is the best one for me to review patches as a whole). If possible, please also change Gerrit to point to a=commitdiff instead of a=commit as above, that's much more useful, IMHO. my mistake, changed some permission - all fixed now. for info gitweb is now working on jenkins too. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gitweb down?
On 20 October 2011 12:06, Spencer Oliver s...@spen-soft.co.uk wrote: On 20 October 2011 11:49, Uwe Hermann u...@hermann-uwe.de wrote: Hi, seems like the gitweb for OpenOCD is down? E.g. the links such as http://openocd.zylin.com/gitweb/?p=openocd.git;a=commit;h=a756b1bcdffef34a6d60d7a2706da9574663f544 no longer work (they did yesterday). There are links from Gerrits pages to the gitweb install, for example (and that's a good thing; please don't drop gitweb, I for one find it very useful; the commitdiff view there is the best one for me to review patches as a whole). If possible, please also change Gerrit to point to a=commitdiff instead of a=commit as above, that's much more useful, IMHO. makes sense - I have changed to use commitdiff Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clang static analyzer
On 18/10/2011 18:18, Øyvind Harboe wrote: Does anyone want to take clang static analyzer for a spin on openocd? http://clang-analyzer.llvm.org/scan-build.html seems jenkins already has a plugin for that :) https://wiki.jenkins-ci.org/display/JENKINS/Clang+Scan-Build+Plugin Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Change in openocd[master]: docs: update project url's
On 13 October 2011 20:47, Uwe Hermann u...@hermann-uwe.de wrote: On Wed, Oct 12, 2011 at 01:04:26PM +0300, Spencer Oliver (Code Review) wrote: Spencer Oliver has submitted this change and it was merged. Change subject: docs: update project url's .. docs: update project url's Change-Id: I54fc3aff722ed25143aad85e58d19b72fcecbba0 Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net --- M NEWTAPS M PATCHES.txt M README M doc/manual/primer/patches.txt M doc/manual/server.txt M doc/openocd.texi 6 files changed, 10 insertions(+), 5 deletions(-) Approvals: Spencer Oliver: Verified; Looks good to me, approved Please configure gerrit so that the full patch is posted on the mailing list additionally, as it used to be. I personally read lots of patches and discussions offline (e.g. in a train) in my mail client, and I'm pretty sure I'm not the only one who'd prefer if patches would still end up on the list (and in the list archive) in addition to gerrit. Thanks! Uwe. -- Hopefully this should be done now - gerrit does not have this feature included yet, so had to write a quick patchset-created hook. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Change in openocd[master]: arm-jtag-ew: whitespace cleanup
Spencer Oliver has uploaded a new change for review. Change subject: arm-jtag-ew: whitespace cleanup .. arm-jtag-ew: whitespace cleanup Change-Id: I8861e825f9c84525e0c09c3adaa3fe300640770d Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net --- M src/jtag/drivers/arm-jtag-ew.c 1 file changed, 17 insertions(+), 28 deletions(-) git pull ssh://openocd.zylin.com:29418/openocd refs/changes/21/21/1 -- To view, visit http://openocd.zylin.com/21 To unsubscribe, visit http://openocd.zylin.com/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I8861e825f9c84525e0c09c3adaa3fe300640770d Gerrit-PatchSet: 1 Gerrit-Project: openocd Gerrit-Branch: master Gerrit-Owner: Spencer Oliver s...@spen-soft.co.uk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Change in openocd[master]: ICEPick-C: Add support for warm reset through JTAG controlle...
Spencer Oliver has uploaded a new change for review. Change subject: ICEPick-C: Add support for warm reset through JTAG controller and provide finer detail functions. .. ICEPick-C: Add support for warm reset through JTAG controller and provide finer detail functions. This sets up simple functions that can later be used to provide additional ICEPick Operations. Change-Id: I313b8679267696fad87d23f3692963e513f2fe21 Signed-off-by: Spencer Oliver s...@spen-soft.co.uk --- M tcl/target/icepick.cfg 1 file changed, 101 insertions(+), 7 deletions(-) git pull ssh://openocd.zylin.com:29418/openocd refs/changes/22/22/1 -- To view, visit http://openocd.zylin.com/22 To unsubscribe, visit http://openocd.zylin.com/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I313b8679267696fad87d23f3692963e513f2fe21 Gerrit-PatchSet: 1 Gerrit-Project: openocd Gerrit-Branch: master Gerrit-Owner: Spencer Oliver s...@spen-soft.co.uk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Change in openocd[master]: AM/DM37x: Use ICEPick warm reset and include halt when gdb c...
Spencer Oliver has uploaded a new change for review. Change subject: AM/DM37x: Use ICEPick warm reset and include halt when gdb connects. .. AM/DM37x: Use ICEPick warm reset and include halt when gdb connects. Using the ICEPick reset seems to allow the processor to be halted sooner and the halt on gdb connection makes the connect process more robust. Change-Id: I0586f6e6becc60a729030509ef58907a19d545ec Signed-off-by: Spencer Oliver s...@spen-soft.co.uk --- M tcl/target/amdm37x.cfg 1 file changed, 28 insertions(+), 19 deletions(-) git pull ssh://openocd.zylin.com:29418/openocd refs/changes/23/23/1 -- To view, visit http://openocd.zylin.com/23 To unsubscribe, visit http://openocd.zylin.com/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I0586f6e6becc60a729030509ef58907a19d545ec Gerrit-PatchSet: 1 Gerrit-Project: openocd Gerrit-Branch: master Gerrit-Owner: Spencer Oliver s...@spen-soft.co.uk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Change in openocd[master]: flash: fix lpc2000 driver typo
Spencer Oliver has uploaded a new change for review. Change subject: flash: fix lpc2000 driver typo .. flash: fix lpc2000 driver typo Change-Id: I3a759ed98a27fd186c12355b846d5e97dba86c5b Signed-off-by: Spencer Oliver s...@spen-soft.co.uk --- M src/flash/nor/lpc2000.c 1 file changed, 1 insertion(+), 3 deletions(-) git pull ssh://openocd.zylin.com:29418/openocd refs/changes/24/24/1 -- To view, visit http://openocd.zylin.com/24 To unsubscribe, visit http://openocd.zylin.com/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I3a759ed98a27fd186c12355b846d5e97dba86c5b Gerrit-PatchSet: 1 Gerrit-Project: openocd Gerrit-Branch: master Gerrit-Owner: Spencer Oliver s...@spen-soft.co.uk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Info about RTOS support
On 13 October 2011 15:21, Øyvind Harboe oyvind.har...@zylin.com wrote: I checked on the http://openocd.sourceforge.net/doc//pdf/openocd.pdf. I did a find on rtos keyword, and find nothing about this. Perhaps that pdf is old, try openocd.texi from HEAD of master. docs are generated weekly so should not be to old. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Change in openocd[master]: target: whitespace cleanup
Spencer Oliver has uploaded a new change for review. Change subject: target: whitespace cleanup .. target: whitespace cleanup Change-Id: I1453f4f3dc0add529da20577e38b8b82d7d00366 Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net --- M src/target/target.c 1 file changed, 36 insertions(+), 40 deletions(-) git pull ssh://openocd.zylin.com:29418/openocd refs/changes/18/18/1 -- To view, visit http://openocd.zylin.com/18 To unsubscribe, visit http://openocd.zylin.com/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I1453f4f3dc0add529da20577e38b8b82d7d00366 Gerrit-PatchSet: 1 Gerrit-Project: openocd Gerrit-Branch: master Gerrit-Owner: Spencer Oliver s...@spen-soft.co.uk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Change in openocd[master]: docs: update project url's
Spencer Oliver has submitted this change and it was merged. Change subject: docs: update project url's .. docs: update project url's Change-Id: I54fc3aff722ed25143aad85e58d19b72fcecbba0 Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net --- M NEWTAPS M PATCHES.txt M README M doc/manual/primer/patches.txt M doc/manual/server.txt M doc/openocd.texi 6 files changed, 10 insertions(+), 5 deletions(-) Approvals: Spencer Oliver: Verified; Looks good to me, approved -- To view, visit http://openocd.zylin.com/15 To unsubscribe, visit http://openocd.zylin.com/settings Gerrit-MessageType: merged Gerrit-Change-Id: I54fc3aff722ed25143aad85e58d19b72fcecbba0 Gerrit-PatchSet: 1 Gerrit-Project: openocd Gerrit-Branch: master Gerrit-Owner: Spencer Oliver s...@spen-soft.co.uk Gerrit-Reviewer: Spencer Oliver s...@spen-soft.co.uk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD Gerrit Review
Hi, We are now testing Gerrit for use within OpenOCD. A Gerrit server has been setup at the following url: http://openocd.zylin.com/ To keep loading down on the server clone as usual: git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd for example The change happens we want to submit a patch for review. Create a account on the Gerrit server above - make sure email matches git email. Add a new remote to git using Gerrit username git remote add review ssh://usern...@openocd.zylin.com:29418/openocd.git git config remote.review.push HEAD:refs/for/master It is advised to keep each patch in its own branch. Once you are happy with the usual git add git commit we are ready to commit to the review server git push review The patch will be reviewed and hopefully committed to git. I will try and put up a page on the website. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD Gerrit Review
On 11 October 2011 13:40, Spencer Oliver s...@spen-soft.co.uk wrote: Hi, We are now testing Gerrit for use within OpenOCD. A Gerrit server has been setup at the following url: http://openocd.zylin.com/ To keep loading down on the server clone as usual: git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd for example The change happens we want to submit a patch for review. Create a account on the Gerrit server above - make sure email matches git email. Add a new remote to git using Gerrit username git remote add review ssh://usern...@openocd.zylin.com:29418/openocd.git git config remote.review.push HEAD:refs/for/master It is advised to keep each patch in its own branch. Once you are happy with the usual git add git commit we are ready to commit to the review server git push review The patch will be reviewed and hopefully committed to git. I will try and put up a page on the website. Cheers Spen One addition i forgot to mention. Gerrit uses a Change-Id to track the change, thsi is generated client side using a hook. You will need to install this hook, we will look into a better solution scp -p -P 29418 usern...@openocd.zylin.com:hooks/commit-msg .git/hooks/ I have also attached here, just place in .git/hooks dir. Cheers Spen commit-msg Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD Gerrit Review
On 11/10/2011 20:54, Øyvind Harboe wrote: Hi Jason, I do share your concern that we're loosing something when we're not using the mailing list to discuss patches. However, I certainly still welcome discussion of patches in the mailing list prior to pushing them to Gerrit. In fact I think that if the entire discussion was in the mailing list and all we used gerrit for was to queue up ready patches to be submitted in due time, then that would be a perfectly acceptable state of affairs. Similarly I think that it's great to clear a lot of the noisy discussions from the mailing list(fix whitespace, remove useless comment, etc.). What I as a maintainer is trying to do is to enable contributors to do more and for the contributors and community to be less dependent on maintainers. We're also looking into getting some verifiers installed on Gerrit so that the computer can take care of checking that whitespace problems are fixed, etc. one thing we could add is that all new additions to gerrit get sent to the mailing list. I did not do this before as it can be enabled on a per user, using the project watch options in gerrit. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Show of hands for/against gerrit
On Oct 6, 2011 10:01 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I find gerrit intriguing as a way of managing patches. Can I have a show of hands of contributors for/against/don't care/don't know? +1 from of :-) Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd mailing lists moving
On 5 October 2011 12:20, Tomek CEDRO tomek.ce...@gmail.com wrote: On Tue, Oct 4, 2011 at 1:26 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Due to the recent news about Berlios closure on 31.12.2011 we are moving the mailing list to sourceforge. http://lists.sourceforge.net/mailman/listinfo/openocd-devel - was http://lists.berlios.de/mailman/listinfo/openocd-development http://lists.sourceforge.net/mailman/listinfo/openocd-commit - was http://lists.berlios.de/mailman/listinfo/openocd-svn was? http://lists.sourceforge.net/mailman/listinfo/openocd-devel - is ? http://lists.berlios.de/mailman/listinfo/openocd-development - was ? http://lists.sourceforge.net/mailman/listinfo/openocd-commit - is ? http://lists.berlios.de/mailman/listinfo/openocd-svn - was ? mmm - must have been a long day Thanks for the correction Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] openocd mailing lists moving
Due to the recent news about Berlios closure on 31.12.2011 we are moving the mailing list to sourceforge. http://lists.sourceforge.net/mailman/listinfo/openocd-devel - was http://lists.berlios.de/mailman/listinfo/openocd-development http://lists.sourceforge.net/mailman/listinfo/openocd-commit - was http://lists.berlios.de/mailman/listinfo/openocd-svn so the list email will change to openocd-de...@lists.sourceforge.net I am hoping that the move will be easy, users will be moved onto the new lists automatically. For info the archives will also be moved. The date has not been set yet but i will keep all informed when it is due to take place. Lastly the website has also been moved - openocd.berlios.de to openocd.sourceforge.net including all online docs. Redirects are in place so the move should be seamless. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: BerliOS will be closed on 31.12.2011
I agree - I will look into it, website aswell. Spen On Sep 30, 2011 6:47 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: FYI, My first instinct is to move the mailing list wholesale to sourceforge. -- Forwarded message -- From: ad...@berlios.de Date: 2011/9/30 Subject: BerliOS will be closed on 31.12.2011 To: ad...@berlios.de Sehr geehrte BerliOS Entwickler und Anwender, BerliOS wurde vor 10 Jahren als eines der ersten Repositories in Europa gegründet. Es wurde von Fraunhofer FOKUS entwickelt und gepflegt. Als ein europäisches, nicht proprietäres Projekt verfolgt BerliOS das Ziel, die verschiedenen Open-Source-Akteure zu unterstützen und eine neutrale Vermittlerfunktion zu bieten. 2011 wurden 4710 Projekte auf BerliOS gehosted, mit 50.000 registrierten Nutzern und über 2,6 Millionen Dateien Downloads jeden Monat. Wir sind stolz, dass wir mit BerliOS die Idee eines OSS-Repository nach Europa gebracht haben. Mittlerweile hat sich das Konzept durchgesetzt und es gibt zahlreiche gute Alternativen. Leider hat ein Forschungsinstitut wie Fraunhofer FOKUS nur wenig Möglichkeiten, langfristig ein Repository wie BerliOS zu betreiben. Ein solches Projekt funktioniert nur, wenn es gelingt, eine Anschlussfinanzierung zu finden, bzw. Sponsoren oder Partner zu gewinnen, die das Repository übernehmen. Das ist im OSS-Bereich ein schwieriges Unterfangen. In einer kürzlich durchgeführten Umfrage haben wir zwar Unterstützung an Geldmitteln und Arbeitsleistung signalisiert bekommen, für die wir uns bedanken. Leider reicht das Ergebnis aber nicht aus, um das Projekt auf eine nachhaltige finanzielle Basis zu stellen. Auch die Suche nach Sponsoren oder Partnern war leider erfolglos. Open Source wird bei Fraunhofer FOKUS als Paradigma für zukunftsweisenden intelligenten IT-Einsatz verstanden. Es schmerzt uns deshalb um so mehr, dass wir gezwungen sind, den Betrieb von BerliOS zum 31.12.2011 einzustellen. * Als Entwickler sollten Sie Ihre BerliOS Projekte in ein anderes Repository exportieren. Alternativen siehe http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities * Auf unserer Website finden Sie einen Leitfaden, wie Sie Ihre Projektdaten aus dem Portal exportieren und in einer anderen Plattform überführen können, siehe http://developer.berlios.de/docman/display_doc.php?docid=2055group_id=2 Fraunhofer FOKUS hat nach wie vor ein starkes Engagement für Open Source und Interoperabilität, engagiert sich erfolgreich in zahlreichen OSS-Projekten. Das Institut konzentriert sich auf die Entwicklung von Qualitätsstandards für Open Source Software und dabei insbesondere auf die technische, semantische und organisatorische Interoperabilität zwischen einzelnen Open Source Software Komponenten sowie zwischen Open Source und Closed Source Software. Beispiel für unsere OSS-Aktivitäten ist unter anderem unsere Leitung des deutschen QualiPSo Competence Center. Wir bedanken uns bei allen, die über die Jahre BerliOS genutzt haben. Fraunhofer FOKUS www.fokus.fraunhofer.de Dear BerliOS developers and users, BerliOS was founded 10 years ago as one of the first repositories in Europe. It was developed and maintained by Fraunhofer FOKUS. As an European, non-proprietary project BerliOS pursued the goal to support the various open-source players and provide a neutral mediator function. In 2011 over 4710 projects have been hosted on BerliOS, with 50,000 registered users and over 2.6 million file downloads each month. We are proud that with BerliOS we have brought the idea of an OSS repository to Europe. Meanwhile, the concept has prevailed and there are many good alternatives. Unfortunately, as a research institute Fraunhofer FOKUS has only few opportunities to operate a repository like BerliOS. Such a project will only work with a follow-up financing, or with sponsors or partners taking over the repository. In the field of OSS this is a difficult undertaking. In a recent survey the community indicated some support in funds and manpower which we would like to thank you for. Unfortunately, the result is not enough to put the project on a sustainable financial basis. In addition the search for sponsors or partners was unsuccessful. Open Source is understood by Fraunhofer FOKUS as a paradigm for future-oriented intelligent use of IT. It hurts us all the more that we are forced to discontinue the hosting for BerliOS by 31.12.2011. * As a developer, you should export your BerliOS project into another repository. Alternatives see http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities * On our site you will find a guide on how to get your project data out of the portal and migrate it in a different platform, see http://developer.berlios.de/docman/display_doc.php?docid=2056group_id=2 Fraunhofer FOKUS has a strong commitment to open source and interoperability, and is
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 16 August 2011 11:03, Steve Bennett ste...@workware.net.au wrote: On 12/08/2011, at 11:12 PM, Xiaofan Chen wrote: On Wed, Aug 10, 2011 at 3:39 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Aug 10, 2011 at 3:34 PM, Olivier Schonken olivier.schon...@gmail.com wrote: Hi Xiaofan In my case I struggled with the same problem for a day or two. That is why I need to know if it is the checkout of the version, or the updating of the mingw32 compiler that fixed the problem. After doing the ./bootstrap command, the head revision of JimTCL is cloned from its repository - afaik. Thus, to get version 0.63 checked out do the following cd jimtcl git tag -l (Gives you a list of the tags for the jimtcl repository) git checkout 0.63 The version of Jimtcl in the directory should now be 0.63. To view the tags of the openocd source, and checkout for instance 0.5.0-rc2 the same procedure is used. Hopefully this helps, cause I've been trying to replicate the problem without success for a while now. This is clear now. I will make sure that my MinGW/Cygwin setup are up to date and see if that helps. If not, I will follow your suggestion and downgrade jimtcl to see if that help. Thanks for the helps! Good news. Spencer and I sorted out the jimtcl build problem on mingw. The fix is in the jimtcl git repo. See: http://repo.or.cz/w/jimtcl.git/commit/645ed6fd4b6f9038c7e1d85d74c3872b3cb9a507 Cheers, Steve yah - i will update the openocd jim version Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 16 August 2011 11:42, Steve Bennett ste...@workware.net.au wrote: On 16/08/2011, at 8:32 PM, Spencer Oliver wrote: On 16 August 2011 11:13, Spencer Oliver s...@spen-soft.co.uk wrote: On 16 August 2011 11:03, Steve Bennett ste...@workware.net.au wrote: On 12/08/2011, at 11:12 PM, Xiaofan Chen wrote: On Wed, Aug 10, 2011 at 3:39 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Aug 10, 2011 at 3:34 PM, Olivier Schonken olivier.schon...@gmail.com wrote: Hi Xiaofan In my case I struggled with the same problem for a day or two. That is why I need to know if it is the checkout of the version, or the updating of the mingw32 compiler that fixed the problem. After doing the ./bootstrap command, the head revision of JimTCL is cloned from its repository - afaik. Thus, to get version 0.63 checked out do the following cd jimtcl git tag -l (Gives you a list of the tags for the jimtcl repository) git checkout 0.63 The version of Jimtcl in the directory should now be 0.63. To view the tags of the openocd source, and checkout for instance 0.5.0-rc2 the same procedure is used. Hopefully this helps, cause I've been trying to replicate the problem without success for a while now. This is clear now. I will make sure that my MinGW/Cygwin setup are up to date and see if that helps. If not, I will follow your suggestion and downgrade jimtcl to see if that help. Thanks for the helps! Good news. Spencer and I sorted out the jimtcl build problem on mingw. The fix is in the jimtcl git repo. See: http://repo.or.cz/w/jimtcl.git/commit/645ed6fd4b6f9038c7e1d85d74c3872b3cb9a507 Cheers, Steve yah - i will update the openocd jim version just updated to latest jim master 645ed6fd4b6f9038c7e1d85d74c3872b3cb9a507 get a jimtcl build error now on cygwin and linux - msys is working fine. cc -g -O2 -rdynamic -o jimsh jimsh.o _initjimsh.o libjim.a -ldl _initjimsh.o: In function `Jim_initjimshInit': /home/soliver/openocd/openocd-rel/jimtcl/_initjimsh.c:6: undefined reference to `Jim_Eval_Named' collect2: ld returned 1 exit status make[2]: *** [jimsh] Error 1 Is this with a clean tree? Jim_Eval_Named() is now a macro rather than a function in jim.h working fine with a clean tree - thanks. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] A fix (was Re: Git revision string missing from banner)
On 15 August 2011 16:03, Jie Zhang jzhang...@gmail.com wrote: On Mon, Aug 15, 2011 at 9:35 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 15 August 2011 14:22, Eric Wetzel thewet...@gmail.com wrote: if test $cross_compiling = no; then # guess-rev.sh only exists in the repository, not in the released archives AC_CHECK_FILE($srcdir/guess-rev.sh, has_guess_rev=yes, has_guess_rev=no) We automatically assume that if we are cross-compiling that we are building a release. This section was last modified in July 2009, back in the SVN days, but the commit is here: http://repo.or.cz/w/openocd.git/commitdiff/00fad24996d6642c6a820cc951c197dddef5734a Actually it was introduced earlier http://repo.or.cz/w/openocd.git/commit/64e53c4fd8a5da944de57716b137a7dff5e67b63 This patch should fix it. Please review and merge if it's OK. Thank you! looks fine to me. thanks spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Rename configure.in as configure.ac
On 15/08/2011 20:42, Jie Zhang wrote: configure.ac is now preferred. So rename configure.in to make OpenOCD project look modern. Please review and merge if it's OK. Thank you! cheers, no objections then i will commit. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build error with mingw32
On Aug 14, 2011 10:01 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Sat, Aug 13, 2011 at 9:38 AM, Jie Zhang jzhang...@gmail.com wrote: On Fri, Aug 12, 2011 at 9:27 PM, Xiaofan Chen xiaof...@gmail.com wrote: This is probably because you have a very old version of MinGW and MinGW Win32-API. Seems to be a problem with Debian. http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/RuntimeLibrary/Win32-API/ Debian seems to ship a 3-year old MinGW Win32-API. http://packages.debian.org/search?searchon=sourcenameskeywords=mingw32 Hmm, good point. I have written an email to the mingw32-runtime package maintainer of Debian to see if he has any plan to update it to the latest version. Hmm, it seems you are out of luck. The Debian MinGW32 maintainer seemed to think there is a licensing issue somewhere and refused to update. You may have to build your own 3.17 version as in the following thread. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498529 Ubuntu has it updated since 9.10 but still stuck with the same old MinGW gcc. Luckily the gcc version is not an issue. I am running 10.04 and 11.04 and have no problems with cross-build OpenOCD. http://changelogs.ubuntu.com/changelogs/pool/universe/m/mingw32-runtime/mingw32-runtime_3.15.2-0ubuntu1/changelog http://changelogs.ubuntu.com/changelogs/pool/universe/m/mingw32/ Openocd checks for usleep and already has a replacement if not found. See replacements.h Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
On 01/08/2011 10:05, Spencer Oliver wrote: On 29 July 2011 22:23, Andreas Fritiofsonandreas.fritiof...@gmail.com wrote: Another fix would be not trying to print the status as a numeric value. We can print it as an error message, so we don't need to handle this tricky situation. Like LOG_ERROR(FT_Write failed:%s\n, ftd2xx_status_string(status)); That sounds *way* better. And more helpful to the user, too. If it's available in all recent ftd2xx versions on all platforms, I'd say it's a go. Any takers for putting together the patch? /Andreas Anyone having a go at this - if not i may get a chance later on in the week? Cheers Spen I have merged a patch that should sort all these warnings out. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
On 11/08/2011 22:14, Jie Zhang wrote: Anyone having a go at this - if not i may get a chance later on in the week? Cheers Spen I have merged a patch that should sort all these warnings out. Thanks. But it's on your git tree, not on the public one, right? it has been merged to openocd master ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
On 10 August 2011 09:13, Øyvind Harboe oyvind.har...@zylin.com wrote: We *do* want all the personal commit logs they are crucial documentation of the system. I am in the rebase camp - i like the linear history. rebase only really effects shared public repos - as our dev's tend to use their own mirror cannot see an issue. fetch will keep their public shared repo in sync, performing a rebase may mean that the dev will need to force an update on his shared public repo. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10 August 2011 07:11, Steve Bennett ste...@workware.net.au wrote: On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: On Wed, Aug 10, 2011 at 11:44 AM, Steve Bennett ste...@workware.net.au wrote: On 10/08/2011, at 9:43 AM, Xiaofan Chen wrote: It was not up to date but very close. Anyway, I just updated it and the issue is still there with the release zip file. I will try the git tree later. === configuring in jimtcl (/cygdrive/d/work/openocd/openocd-0.5.0/build_mingw_cr oss/jimtcl) configure: running /bin/sh ../../jimtcl/configure.gnu --disable-option-checking '--prefix=/usr/local' '--build=i686-pc-mingw32' '--enable-jlink' '--enable-ft22 32_libftdi' 'build_alias=i686-pc-mingw32' --cache-file=/dev/null --srcdir=../../ jimtcl ../../jimtcl/configure: line 3: D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j : No such file or directory ../../jimtcl/configure: line 3: exec: D:/work/openocd/openocd-0.5.0/jimtcl/autos : cannot execute: No such file or directory configure: error: ../../jimtcl/configure.gnu failed for jimtcl You have something weird going on there. Note how the lines are truncated. For example: ../../jimtcl/configure: line 3: D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j : No such file or directory Yes I agree that the error message is quite strange. It is directly copy and paste from the Cygwin prompt. I will check again. The other errors under MinGW are also quite strange. I think I will try another setup. Let us know how that goes. Or is that your cut and paste of the error messages? If so, please add the errors as an attachment instead. FYI: I build the release tarball on windows/mingw without any problems. Glad to know that. As per the previous answer from Spen that MinGW/Msys is not supported by jimtcl. Is that not true? That is *not* true. The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys for me jimtcl has never built under msys since the update. log is attached below, for info jimsh0.exe is built ok. No installed jimsh or tclsh, building local bootstrap jimsh0 The system cannot find the path specified. autosetup/system.tcl:150: Error: in procedure 'use' called at file auto.def, line 5 in procedure 'use' called at file autosetup/cc.tcl, line 29 in procedure 'config_guess' called at file autosetup/system.tcl, line 150 Try: 'configure --debug' for a full stack trace configure: error: ./configure.gnu failed for jimtcl Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10 August 2011 11:15, Steve Bennett ste...@workware.net.au wrote: On 10/08/2011, at 6:39 PM, Spencer Oliver wrote: On 10 August 2011 07:11, Steve Bennett ste...@workware.net.au wrote: On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: On Wed, Aug 10, 2011 at 11:44 AM, Steve Bennett ste...@workware.net.au wrote: On 10/08/2011, at 9:43 AM, Xiaofan Chen wrote: It was not up to date but very close. Anyway, I just updated it and the issue is still there with the release zip file. I will try the git tree later. === configuring in jimtcl (/cygdrive/d/work/openocd/openocd-0.5.0/build_mingw_cr oss/jimtcl) configure: running /bin/sh ../../jimtcl/configure.gnu --disable-option-checking '--prefix=/usr/local' '--build=i686-pc-mingw32' '--enable-jlink' '--enable-ft22 32_libftdi' 'build_alias=i686-pc-mingw32' --cache-file=/dev/null --srcdir=../../ jimtcl ../../jimtcl/configure: line 3: D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j : No such file or directory ../../jimtcl/configure: line 3: exec: D:/work/openocd/openocd-0.5.0/jimtcl/autos : cannot execute: No such file or directory configure: error: ../../jimtcl/configure.gnu failed for jimtcl You have something weird going on there. Note how the lines are truncated. For example: ../../jimtcl/configure: line 3: D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j : No such file or directory Yes I agree that the error message is quite strange. It is directly copy and paste from the Cygwin prompt. I will check again. The other errors under MinGW are also quite strange. I think I will try another setup. Let us know how that goes. Or is that your cut and paste of the error messages? If so, please add the errors as an attachment instead. FYI: I build the release tarball on windows/mingw without any problems. Glad to know that. As per the previous answer from Spen that MinGW/Msys is not supported by jimtcl. Is that not true? That is *not* true. The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys for me jimtcl has never built under msys since the update. log is attached below, for info jimsh0.exe is built ok. No installed jimsh or tclsh, building local bootstrap jimsh0 The system cannot find the path specified. autosetup/system.tcl:150: Error: in procedure 'use' called at file auto.def, line 5 in procedure 'use' called at file autosetup/cc.tcl, line 29 in procedure 'config_guess' called at file autosetup/system.tcl, line 150 Try: 'configure --debug' for a full stack trace configure: error: ./configure.gnu failed for jimtcl It is failing while trying to run config.guess. What do you get when you run: sh jimtcl/autosetup/config.guess i686-pc-mingw32 just installed a fresh copy of msys/mingw - still same error. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10 August 2011 13:30, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Aug 10, 2011 at 6:35 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 10 August 2011 11:15, Steve Bennett ste...@workware.net.au wrote: for me jimtcl has never built under msys since the update. log is attached below, for info jimsh0.exe is built ok. No installed jimsh or tclsh, building local bootstrap jimsh0 The system cannot find the path specified. autosetup/system.tcl:150: Error: in procedure 'use' called at file auto.def, line 5 in procedure 'use' called at file autosetup/cc.tcl, line 29 in procedure 'config_guess' called at file autosetup/system.tcl, line 150 Try: 'configure --debug' for a full stack trace configure: error: ./configure.gnu failed for jimtcl It is failing while trying to run config.guess. What do you get when you run: sh jimtcl/autosetup/config.guess i686-pc-mingw32 just installed a fresh copy of msys/mingw - still same error. I can reproduce here at a Vista 32bit installation of MinGW/MSys. It is a myth now that I have the other PC working (XP SP3). I have updated both MinGW/MSys installation to the latest. === configuring in jimtcl (/d/work/openocd/openocd-0.5.0/build_mingw/jimtcl) configure: running /bin/sh ../../jimtcl/configure.gnu --disable-option-checking '--prefix=/usr/local' '--enable-jlink' '--enable-ft2232_libftdi' --cache-file=/ dev/null --srcdir=../../jimtcl No installed jimsh or tclsh, building local bootstrap jimsh0 The system cannot find the path specified. ../../jimtcl/autosetup/system.tcl:150: Error: in procedure 'use' called at file ../../jimtcl/auto.def, line 5 in procedure 'use' called at file ../../jimtcl/autosetup/cc.tcl, line 29 in procedure 'config_guess' called at file ../../jimtcl/autosetup/system.tcl, line 150 Try: 'configure --debug' for a full stack trace configure: error: ../../jimtcl/configure.gnu failed for jimtcl we are currently working on this issue offlist, hopefully soon resolved. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10 August 2011 13:26, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 11:11 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 9 August 2011 16:01, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Just tested building native windoze under cygwin and working fine here. I used the release tarball and the following configure line: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx Try build in a separate build directory and see if that is okay or not. works fine in/out of src tree. Just to be sure i also deleted the release src tree between builds. This is the key here. It seems to me that jimtcl build is a bit strange that it creates a jimsh0.exe under the source distribution (jimtcl\autosetup directory) even though I am building out of source tree. And that seems to cause problems for subsequent build if I change the build type. You are correct about the location of jimsh0 and it was pointed out to Steve a while back. However i have not seen any issues caused by this under cygwin. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10/08/2011 14:41, Jie Zhang wrote: On Wed, Aug 10, 2011 at 9:29 AM, Xiaofan Chenxiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 10:20 PM, Spencer Olivers...@spen-soft.co.uk wrote: Just tested building native windoze under cygwin and working fine here. I used the release tarball and the following configure line: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx Yes --disable-werror is necessary. If not the following errors will come out. I remember Jie Zheng has some proposals to fix this. ../../../../src/jtag/drivers/ft2232.c: In function 'ft2232_write': ../../../../src/jtag/drivers/ft2232.c:518:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' Yes. And Spencer said he would fix it if he got a chance. Jie http://repo.or.cz/w/openocd/ntfreak.git ftdi Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On 9 August 2011 10:31, Tomek CEDRO tomek.ce...@gmail.com wrote: On Tue, Aug 9, 2011 at 8:53 AM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 07:50 Tue 09 Aug , Tomek CEDRO wrote: Ugh, why this is a release not RC3? We did not test RC to have go for a release... are we supposed to test on a release? :\ there was no patch during day so as I said no rc we get more than 4weeks of fix windows it's enough If some bug are found on the release we will create bugfix release 0.5.x OK then, seems there will be more releases with build/revision higher than 0 :-) Please provide correct/complete RC packages next time as this is also important for testing :-) Best regards :-) Tomek Just for info i have also pushed files onto berlios and updated website with release news. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 9 August 2011 12:52, Vit Mares mares@gmail.com wrote: Attempt to build 0.5.0 with MinGW on Windows XP failed when running configure. Release 0.4.0 configured and built without problems. config.status: creating src/pld/Makefile config.status: creating doc/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands === configuring in jimtcl (/home/maresv/openocd-0.5.0/jimtcl) configure: running /bin/sh ./configure.gnu --disable-option-checking '--prefix=/home/maresv/openocd_dist_050' '--enable -parport' '--enable-parport-giveio' '--enable-ft2232_ftd2xx' '--with-ftd2xx-win32-zipdir=/home/maresv/drivers_ftdi' --ca che-file=/dev/null --srcdir=. The system cannot find the path specified. autosetup/system.tcl:150: Error: in procedure 'use' called at file auto.def, line 5 in procedure 'use' called at file autosetup/cc.tcl, line 29 in procedure 'config_guess' called at file autosetup/system.tcl, line 150 Try: 'configure --debug' for a full stack trace configure: error: ./configure.gnu failed for jimtcl Best regards Vit Mares As far as i am aware jimtcl does not support building under msys. I have tested building win32/64 native binaries under cygwin and linux - both these are working. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 9 August 2011 13:48, Vit Mares mares@gmail.com wrote: Hi Spen, it doesn't seem so, jimsh0.exe is built during configure and is runable. When I start it in MSYS console I get the dot prompt. Best regards Vit It has been a while since i looked however: Building jimsh0 is not the problem, running it is - the scripts look for jimsh0 and under msys this should be jimsh0.exe. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 9 August 2011 14:13, Jie Zhang jzhang...@gmail.com wrote: On Tue, Aug 9, 2011 at 7:52 AM, Vit Mares mares@gmail.com wrote: Attempt to build 0.5.0 with MinGW on Windows XP failed when running configure. Release 0.4.0 configured and built without problems. I downloaded 0.5.0 and built it with mingw-w64 on Debian testing. The build was successful. But I didn't try the resulted binary. The issue is building using msys under windoze. Using cygwin or linux to build native win32 (mingw) is not an issue. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 9 August 2011 14:34, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 9:25 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 9 August 2011 13:48, Vit Mares mares@gmail.com wrote: it doesn't seem so, jimsh0.exe is built during configure and is runable. When I start it in MSYS console I get the dot prompt. It has been a while since i looked however: Building jimsh0 is not the problem, running it is - the scripts look for jimsh0 and under msys this should be jimsh0.exe. Just wondering if this could be fixed. I think many Windows users would like to be able to build under MinGW/MSys instead of Cygwin (quite slow). Hoping it will get fixed, however that part is todo with jimtcl and i do not understand their build system. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 9 August 2011 15:10, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 10:05 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 9:47 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 9:27 PM, Spencer Oliver s...@spen-soft.co.uk wrote: The issue is building using msys under windoze. Using cygwin or linux to build native win32 (mingw) is not an issue. I remember there were no issues to build MinGW binary under Cygwin with the cross compiler with OpenOCD git. But it seems that there are problems with the 0.5.0 release tar ball. Actually build under Cygwin is also problematic. Luckily git tree is still okay for Cygwin native build and Cygwin MinGW cross build. But only Cygwin native build is okay. $ openocd -v Open On-Chip Debugger 0.6.0-dev-2-gdb87a2f-dirty (2011-08-09-22:03) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html MinGW cross build under Cygwin fails because of jimtcl. Just tested building native windoze under cygwin and working fine here. I used the release tarball and the following configure line: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 9 August 2011 16:01, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Just tested building native windoze under cygwin and working fine here. I used the release tarball and the following configure line: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx Try build in a separate build directory and see if that is okay or not. works fine in/out of src tree. Just to be sure i also deleted the release src tree between builds. are your cygwin tools upto date? Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 9 August 2011 16:11, Spencer Oliver s...@spen-soft.co.uk wrote: On 9 August 2011 16:01, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Just tested building native windoze under cygwin and working fine here. I used the release tarball and the following configure line: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx Try build in a separate build directory and see if that is okay or not. works fine in/out of src tree. Just to be sure i also deleted the release src tree between builds. are your cygwin tools upto date? can you run make distcheck on your normal dev tree. This is what has been used to check that the release tarball works. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PULL Request] Flash program speedup through asynchronous algorithms
On 09/08/2011 22:15, Øyvind Harboe wrote: Any objections? I would like to give this a test-run tomorrow. One observation - other targets that do not yet support the new functions will output a LOG_ERROR to the user. Maybe this should be a LOG_DEBUG as the user will have no idea what it means. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 07:56, Øyvind Harboe oyvind.har...@zylin.com wrote: When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) Release tags are annotated, and so take priority with git describe. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] arm11: disable broken optimization for setting current scan chain
On 5 August 2011 09:00, Øyvind Harboe oyvind.har...@zylin.com wrote:
---
src/target/arm11_dbgtap.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/target/arm11_dbgtap.c b/src/target/arm11_dbgtap.c
index 5c671cc..c6c5a50 100644
--- a/src/target/arm11_dbgtap.c
+++ b/src/target/arm11_dbgtap.c
@@ -199,11 +199,15 @@ int arm11_add_debug_SCAN_N(struct arm11_common *arm11,
* NOTE: the ITRSEL instruction fakes SCREG changing;
* but leaves its actual value unchanged.
*/
- if (arm11-jtag_info.cur_scan_chain == chain) {
- JTAG_DEBUG(SCREG = %d SKIPPED, chain);
- return jtag_add_statemove((state == ARM11_TAP_DEFAULT)
- ? TAP_DRPAUSE : state);
- }
+ // FIX!!! the optimization below is broken because we do not
+ // invalidate the cur_scan_chain upon a TRST/TMS. See arm_jtag.c
+ // for example on how to invlidate cur_scan_chain. Tested patches
gladly
+ // accepted!
+// if (arm11-jtag_info.cur_scan_chain == chain) {
+// JTAG_DEBUG(SCREG = %d SKIPPED, chain);
+// return jtag_add_statemove((state == ARM11_TAP_DEFAULT)
+// ? TAP_DRPAUSE : state);
+// }
JTAG_DEBUG(SCREG = %d, chain);
arm11_add_IR(arm11, ARM11_SCAN_N, ARM11_TAP_DEFAULT);
--
1.7.2.3
better with #if 0 rather than commenting out.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Last call before release
On 5 August 2011 04:38, Rodrigo Rosa rodrigorosa...@gmail.com wrote: I submitted these patches a couple weeks ago, i guess everybody was too busy with the release... Could they be added? Thanks! Sorry should have replied to your original email - i have put them in my patch todo list. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 09:58, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) As I posted several times already, it's because the release procedure wasn't followed in creating the rc tags and tarballs. The following basic steps should be followed for a proper rc3 release. There are more things to take in consideration, for example making sure the NEWS file is properly updated and so on. Check the release manual that Zach and David wrote. 1. Manually fix, commit and push the skipped version bumps in configure.in: -AC_INIT([openocd], [0.5.0-dev], +AC_INIT([openocd], [0.5.0-rc3-dev], 2. do a fresh git clone of openocd 3. run tools/release.sh --next rc release 4. verify and publish archives/* 5. merge v0.5.0-rc4-dev into master and push it After this, git describe correctly reflects that we're in rc phase: v0.5.0-rc3-1-gbcded6a And version strings should be correct (didn't test): 0.5.0-rc3 if built from tarball, 0.5.0-rc4-dev if built from git HEAD. I think we really need to do this, like, right now, then wait for feedback from people building the released rc3 tarballs (a week tops), then do the final 0.5.0 release. No patches accepted except build and packaging fixes after rc3 is out. Final 0.5.0 release is very similar: 1. do a fresh git clone of openocd 2. run tools/release.sh --next minor --final release 3. verify and publish archives/* 4. merge v0.6.0-dev into master and push it /Andreas I will agree that the release process has not been followed with regards to tarballs. However this is not the cause of Øyvind query - please see my previous email. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 10:19, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 11:02 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 5 August 2011 09:58, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) As I posted several times already, it's because the release procedure wasn't followed in creating the rc tags and tarballs. I will agree that the release process has not been followed with regards to tarballs. However this is not the cause of Øyvind query - please see my previous email. Release tags are annotated, and so take priority with git describe. Ok, but if the release script would have been used, the v0.5.0-rc* tags would have been annotated. And they really should be, right? That's what the script does, the 0.4.0 and 0.3.0 rc tags were annotated, and it corresponds with Øyvind's initial expectation of a v0.5.0-rc2- output from git describe. /Andreas Release tags are annotated, but not rc tags Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 10:26, Spencer Oliver s...@spen-soft.co.uk wrote: On 5 August 2011 10:19, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 11:02 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 5 August 2011 09:58, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) As I posted several times already, it's because the release procedure wasn't followed in creating the rc tags and tarballs. I will agree that the release process has not been followed with regards to tarballs. However this is not the cause of Øyvind query - please see my previous email. Release tags are annotated, and so take priority with git describe. Ok, but if the release script would have been used, the v0.5.0-rc* tags would have been annotated. And they really should be, right? That's what the script does, the 0.4.0 and 0.3.0 rc tags were annotated, and it corresponds with Øyvind's initial expectation of a v0.5.0-rc2- output from git describe. /Andreas Release tags are annotated, but not rc tags use git describe --tags to take all tags (including soft) into account. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 10:39, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 11:26 AM, Spencer Oliver s...@spen-soft.co.uk wrote: Release tags are annotated, but not rc tags Oh, but they are, or am I completely oblivious of git tags (quite possible)? $ git checkout v0.4.0-rc2~2 $ git describe v0.4.0-rc1-193-g747a607 http://repo.or.cz/w/openocd.git/tag/cd8ad2e961d3476ddfad3353390ce99a4872bdf1 http://repo.or.cz/w/openocd.git/tag/f74fdc5e4afc94b65cba4b4c357f0e67cc9d185a And why shouldn't they be? /Andreas No sorry you are correct - the rc tags should be annotated aswell. The current 0.5.0-rc* are soft tags not annotated, which is incorrect. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 11:07, Øyvind Harboe oyvind.har...@zylin.com wrote: And why shouldn't they be? To me it's a matter of taste if rc candidate tags are annotated or not. I'm good with either choice. I was just curious as to whether it was accidental or intentional. Looks like it was accidental in that we really should be using the release procedure and when we do, then we get the annotated rc tags. guessing by accident. If we had used the release.sh script this would not have happened. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Automatically generate ChangeLog from git log for release tarball
On 3 August 2011 11:28, Luca Bruno lu...@debian.org wrote: Andreas Fritiofson scrisse: make dist should use git2cl to genereate ChangeLog from git history, populating the placeholder file in released tarball. Still not working for srcdir != builddir make[1]: Entering directory `/home/soliver/openocd/openocd-rel' if test -d ../openocd/.git -a \( ! -e openocd-0.5.0-dev/ChangeLog -o -w openocd-0.5.0-dev/ChangeLog \) ; then \ ../openocd/tools/git2cl/git2cl openocd-0.5.0-dev/ChangeLog ; \ fi fatal: Not a git repository (or any of the parent directories): .git Current directory needs to be $(srcdir) before running git2cl. I suspect this will get tricky, as $(distdir) is relative to $(builddir). It could be easier to directly feed git2cl with a pipe from `git log -- $(srcdir)`, as in the attached patch. Spen, can you please check if this is ok for you? Jean-Christophe, could you consider it for inclusion in 0.5.0 (if ACKed)? Ciao, Luca Replaced the following line and working out of tree - not tested inline if test -d $(srcdir)/.git -a \( ! -e $(distdir)/ChangeLog -o -w $(distdir)/ChangeLog \) ; then \ git --git-dir $(srcdir)/.git log | $(srcdir)/tools/git2cl/git2cl $(distdir)/ChangeLog ; \ fi Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Automatically generate ChangeLog from git log for release tarball
On 3 August 2011 11:46, Spencer Oliver s...@spen-soft.co.uk wrote: On 3 August 2011 11:28, Luca Bruno lu...@debian.org wrote: Andreas Fritiofson scrisse: make dist should use git2cl to genereate ChangeLog from git history, populating the placeholder file in released tarball. Still not working for srcdir != builddir make[1]: Entering directory `/home/soliver/openocd/openocd-rel' if test -d ../openocd/.git -a \( ! -e openocd-0.5.0-dev/ChangeLog -o -w openocd-0.5.0-dev/ChangeLog \) ; then \ ../openocd/tools/git2cl/git2cl openocd-0.5.0-dev/ChangeLog ; \ fi fatal: Not a git repository (or any of the parent directories): .git Current directory needs to be $(srcdir) before running git2cl. I suspect this will get tricky, as $(distdir) is relative to $(builddir). It could be easier to directly feed git2cl with a pipe from `git log -- $(srcdir)`, as in the attached patch. Spen, can you please check if this is ok for you? Jean-Christophe, could you consider it for inclusion in 0.5.0 (if ACKed)? Ciao, Luca Full amended patch below: No objections i will commit. Spen From bc7f9b5ff0be806d27e88ffcc570f120691a299f Mon Sep 17 00:00:00 2001 From: Luca Bruno lu...@debian.org Date: Wed, 3 Aug 2011 14:20:06 +0100 Subject: [PATCH] Automatically generate ChangeLog from git log for release tarball make dist should use git2cl to generate ChangeLog from git history, populating the placeholder file in released tarball. Signed-off-by: Luca Bruno lu...@debian.org Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net --- Makefile.am |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index 461bca4..7bc25af 100644 --- a/Makefile.am +++ b/Makefile.am @@ -68,6 +68,9 @@ TCL_FILES = find $(srcdir)/$(TCL_PATH) -name '*.cfg' -o -name '*.tcl' | \ sed -e 's,^$(srcdir)/$(TCL_PATH),,' dist-hook: + if test -d $(srcdir)/.git -a \( ! -e $(distdir)/ChangeLog -o -w $(distdir)/ChangeLog \) ; then \ + git --git-dir $(srcdir)/.git log | $(srcdir)/tools/git2cl/git2cl $(distdir)/ChangeLog ; \ + fi for i in $$($(TCL_FILES)); do \ j=$(distdir)/$(TCL_PATH)/$$i \ mkdir -p $$(dirname $$j) \ -- 1.7.0.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Automatically generate ChangeLog from git log for release tarball
On 3 August 2011 15:00, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Wed, Aug 3, 2011 at 12:28 PM, Luca Bruno lu...@debian.org wrote: Andreas Fritiofson scrisse: make dist should use git2cl to genereate ChangeLog from git history, populating the placeholder file in released tarball. Still not working for srcdir != builddir make[1]: Entering directory `/home/soliver/openocd/openocd-rel' if test -d ../openocd/.git -a \( ! -e openocd-0.5.0-dev/ChangeLog -o -w openocd-0.5.0-dev/ChangeLog \) ; then \ ../openocd/tools/git2cl/git2cl openocd-0.5.0-dev/ChangeLog ; \ fi fatal: Not a git repository (or any of the parent directories): .git Current directory needs to be $(srcdir) before running git2cl. I suspect this will get tricky, as $(distdir) is relative to $(builddir). If that's always the case it's not that tricky: cd $(srcdir); tools/git2cl/git2cl $(builddir)/$(distdir)/ChangeLog If it's not necessarily relative, this should work better: cd $(srcdir); tools/git2cl/git2cl $(abspath $(distdir)/ChangeLog) Although abspath requires GNU Make 3.81. If the pipe method work, fine. However, looking through the git2cl code it apparently assumes git log is run with LC_ALL=C and that wouldn't be the case with the latest incarnation of the patch. /Andreas Have a look at the modified patch i posted, build ok in/out of tree. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Luminary config script patch
On 2 August 2011 03:05, B bbcu2...@gmail.com wrote: My apologizes I left an extraneous word on a comment line that shouldn't have been in the patch. Here is the same patch, without the needless word. Brian changed wording to DEVICECLASS and committed. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
On 29 July 2011 22:23, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: Another fix would be not trying to print the status as a numeric value. We can print it as an error message, so we don't need to handle this tricky situation. Like LOG_ERROR(FT_Write failed:%s\n, ftd2xx_status_string(status)); That sounds *way* better. And more helpful to the user, too. If it's available in all recent ftd2xx versions on all platforms, I'd say it's a go. Any takers for putting together the patch? /Andreas Anyone having a go at this - if not i may get a chance later on in the week? Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Reset fails LM3S Tempest C5 due to failure to read device class
On 30 July 2011 22:48, B bbcu2...@gmail.com wrote:
Using Open On-Chip Debugger 0.5.0-dev-00948-gd4cd6f0 (2011-07-30-15:55)
LM3S3N26-C5 is not detected as a Tempest device and so uses the sysresetreq
in place of the needed vectreset in stellaris.cfg.
The device class appears to be set by:
set device_class [expr (([mrw 0x400fe000] 16) 0xff)]
This memory location contains the device class. Tempest is 0x04.
There is an errata where LM3S3N26 misreports itself as 0x03.
My attempt at a workaround was to define a variable:
set DEVICECLASSIS 0x04
then call a modified stellaris.cfg:
if { [info exists DEVICECLASSIS ] } {
set device_class $DEVICECLASSIS
} else {
set device_class [expr (([mrw 0x400fe000] 16) 0xff)]
}
if {$device_class == 0 || $device_class == 1 || $device_class == 3} {
# Sandstorm, Fury and DustDevil are able to use NVIC SYSRESETREQ
cortex_m3 reset_config sysresetreq
} else {
# Tempest and newer default to using NVIC VECTRESET
# this does mean a reset-init event handler is required to reset
# any peripherals
cortex_m3 reset_config vectreset
}
The if statement doesn't seem to work properly. Changing the sysresetreq to
vectreset by hand does resolve the issue.
Is there something wrong with my if info exists workaround syntax?
you need to use global - see pic32mx.cfg for an example
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Better fixes for set but not used warnings
On 29 July 2011 16:54, Jie Zhang jzhang...@gmail.com wrote: On Fri, Jul 29, 2011 at 11:41 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 29 July 2011 15:32, Jie Zhang jzhang...@gmail.com wrote: I happened to find that two previous fixes for set-but-not-used warnings are not correct or not good. This patch should be an improvement. Please review and merge if good. I am going to look into tis one, as one minute the code is there, next minute it was deleted - very strange. To ease your review, the related commits are f6315d5e5b7b71515ef051711e5f818a42d6b3b3 smp.c 1cfb2287a67c1f78b76583b2e5ed83ca3560b0d5 etb.c Cool you patch looks fine - i will commit. Just for info this function was first broken in d7f71e7fe9645fa8c3f88cf6fc9ad438aa6708f3. The whitespace cleanup was a very strict indeed :) Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] etb: fix incorrect previous patchset
From: Jie Zhang jzhang...@gmail.com
This corrects two issues found with openocd.
d7f71e7fe9645fa8c3f88cf6fc9ad438aa6708f3 removed some code that was
being used.
The above then caused even more code to get removed by commit
1cfb2287a67c1f78b76583b2e5ed83ca3560b0d5
removed some more code.
Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net
---
src/target/etb.c | 12
src/target/smp.c |9 +
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/target/etb.c b/src/target/etb.c
index 3cb2254..974ab2b 100644
--- a/src/target/etb.c
+++ b/src/target/etb.c
@@ -304,20 +304,32 @@ static int etb_write_reg(struct reg *reg, uint32_t value)
{
struct etb_reg *etb_reg = reg-arch_info;
uint8_t reg_addr = etb_reg-addr 0x7f;
+ struct scan_field fields[3];
LOG_DEBUG(%i: 0x%8.8 PRIx32 , (int)(etb_reg-addr), value);
etb_scann(etb_reg-etb, 0x0);
etb_set_instr(etb_reg-etb, 0xc);
+ fields[0].num_bits = 32;
uint8_t temp0[4];
+ fields[0].out_value = temp0;
buf_set_u32(temp0, 0, 32, value);
+ fields[0].in_value = NULL;
+ fields[1].num_bits = 7;
uint8_t temp1;
+ fields[1].out_value = temp1;
buf_set_u32(temp1, 0, 7, reg_addr);
+ fields[1].in_value = NULL;
+ fields[2].num_bits = 1;
uint8_t temp2;
+ fields[2].out_value = temp2;
buf_set_u32(temp2, 0, 1, 1);
+ fields[2].in_value = NULL;
+
+ jtag_add_dr_scan(etb_reg-etb-tap, 3, fields, TAP_IDLE);
return ERROR_OK;
}
diff --git a/src/target/smp.c b/src/target/smp.c
index f4adc8d..ec157d3 100644
--- a/src/target/smp.c
+++ b/src/target/smp.c
@@ -79,7 +79,7 @@ int gdb_read_smp_packet(struct connection *connection,
hex_buffer[2 * i + 1] = DIGITS[t 0xf];
}
- gdb_put_packet(connection, hex_buffer, len * 2);
+ retval = gdb_put_packet(connection, hex_buffer, len *
2);
free(hex_buffer);
}
@@ -95,6 +95,7 @@ int gdb_write_smp_packet(struct connection *connection,
{
char *separator;
int coreid = 0;
+ int retval = ERROR_OK;
/* skip command character */
if (target-smp)
@@ -104,13 +105,13 @@ int gdb_write_smp_packet(struct connection *connection,
packet+=2;
coreid = strtoul(packet, separator, 16);
target-gdb_service-core[1] = coreid;
- gdb_put_packet(connection, OK, 2);
+ retval = gdb_put_packet(connection, OK, 2);
}
}
else
{
- gdb_put_packet(connection,E01,3);
+ retval = gdb_put_packet(connection,E01,3);
}
- return ERROR_OK;
+ return retval;
}
--
1.7.0.4
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 4/4] flash: add support for deprecated stm32 flash cmds
On 29 July 2011 02:01, Steve Bennett ste...@workware.net.au wrote:
I don't know what parameters may be passed to these procs, but if they could
contain
spaces, quotes or braces this could cause unexpected behaviour.
You might consider using the more correct form:
proc stm32f2xxx args {
echo DEPRECATED! use 'stm32f2x $args' not 'stm32f2xxx $args'
tailcall stm32f2x {*}$args
}
Thanks, i am no tcl expert - far from it.
I just copied existing openocd code, i have tested the args and they
all work as expected in this case.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
On 29 July 2011 11:45, Jie Zhang jzhang...@gmail.com wrote:
Hi,
OpenOCD uses script command to execute config file passed through -f
option. script command is defined as a function
proc script {filename} {
source [find $filename]
}
Thus when executing the config file, global variables defined in that
config file is not global any more. If I define a global variable
set foo 1
in target config file, then trying to read its value by
obj = Jim_GetGlobalVariableStr (interp, foo, 0);
Jim_GetLong(interp, obj, foo);
use global, eg.
global foo
set foo 1
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/4] cfg: update scripts to use new stm32 driver names
On 29 July 2011 14:54, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Thu, Jul 28, 2011 at 1:52 PM, Spencer Oliver s...@spen-soft.co.uk wrote: delete mode 100644 tcl/target/stm32.cfg delete mode 100644 tcl/target/stm32f2xxx.cfg see patch 4 Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/4] cfg: update scripts to use new stm32 driver names
On 29 July 2011 15:43, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: That one won't help for all scripts out there that are currently sourcing target/stm32.cfg. /Andreas Good point - how about http://repo.or.cz/w/openocd/ntfreak.git/commit/e4908b71bcac1e3ae01a4f54cffe475b0be6e336 Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/4] cfg: update scripts to use new stm32 driver names
On 29 July 2011 16:56, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Jul 29, 2011 at 5:38 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 29 July 2011 15:43, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: That one won't help for all scripts out there that are currently sourcing target/stm32.cfg. /Andreas Good point - how about http://repo.or.cz/w/openocd/ntfreak.git/commit/e4908b71bcac1e3ae01a4f54cffe475b0be6e336 stm32f2xxx.cfg sources itself. Other than that, it should do the trick. /Andreas good catch - and fixed ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 3/4] cfg: update scripts to use new stm32 driver names
From: Spencer Oliver ntfr...@users.sourceforge.net
Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net
---
tcl/board/hitex_stm32-performancestick.cfg |2 +-
tcl/board/olimex_stm32_h103.cfg|2 +-
tcl/board/olimex_stm32_h107.cfg|2 +-
tcl/board/stm32100b_eval.cfg |2 +-
tcl/board/stm3210b_eval.cfg|2 +-
tcl/board/stm3210c_eval.cfg|2 +-
tcl/board/stm3210e_eval.cfg|2 +-
tcl/board/stm3220g_eval.cfg|2 +-
tcl/target/stm32.cfg | 75
tcl/target/stm32f1x.cfg| 75
tcl/target/stm32f2x.cfg| 61 ++
tcl/target/stm32f2xxx.cfg | 61 --
tcl/target/stm32xl.cfg |4 +-
13 files changed, 146 insertions(+), 146 deletions(-)
delete mode 100644 tcl/target/stm32.cfg
create mode 100644 tcl/target/stm32f1x.cfg
create mode 100644 tcl/target/stm32f2x.cfg
delete mode 100644 tcl/target/stm32f2xxx.cfg
diff --git a/tcl/board/hitex_stm32-performancestick.cfg
b/tcl/board/hitex_stm32-performancestick.cfg
index 515f7e0..0ec4076 100644
--- a/tcl/board/hitex_stm32-performancestick.cfg
+++ b/tcl/board/hitex_stm32-performancestick.cfg
@@ -5,7 +5,7 @@ reset_config trst_and_srst
source [find interface/stm32-stick.cfg]
set CHIPNAME stm32_hitex
-source [find target/stm32.cfg]
+source [find target/stm32f1x.cfg]
# configure str750 connected to jtag chain
# FIXME -- source [find target/str750.cfg] after cleaning that up
diff --git a/tcl/board/olimex_stm32_h103.cfg b/tcl/board/olimex_stm32_h103.cfg
index 98b0b65..ec03034 100644
--- a/tcl/board/olimex_stm32_h103.cfg
+++ b/tcl/board/olimex_stm32_h103.cfg
@@ -4,4 +4,4 @@
# Work-area size (RAM size) = 20kB for STM32F103RB device
set WORKAREASIZE 0x5000
-source [find target/stm32.cfg]
+source [find target/stm32f1x.cfg]
diff --git a/tcl/board/olimex_stm32_h107.cfg b/tcl/board/olimex_stm32_h107.cfg
index c21e19b..1d34a23 100644
--- a/tcl/board/olimex_stm32_h107.cfg
+++ b/tcl/board/olimex_stm32_h107.cfg
@@ -5,4 +5,4 @@
# Work-area size (RAM size) = 64kB for STM32F107VC device
set WORKAREASIZE 0x1
-source [find target/stm32.cfg]
+source [find target/stm32f1x.cfg]
diff --git a/tcl/board/stm32100b_eval.cfg b/tcl/board/stm32100b_eval.cfg
index e04b612..41153e5 100644
--- a/tcl/board/stm32100b_eval.cfg
+++ b/tcl/board/stm32100b_eval.cfg
@@ -4,4 +4,4 @@
# The chip has only 8KB sram
set WORKAREASIZE 0x2000
-source [find target/stm32.cfg]
+source [find target/stm32f1x.cfg]
diff --git a/tcl/board/stm3210b_eval.cfg b/tcl/board/stm3210b_eval.cfg
index 70798c1..ff3f777 100644
--- a/tcl/board/stm3210b_eval.cfg
+++ b/tcl/board/stm3210b_eval.cfg
@@ -4,4 +4,4 @@
# increase working area to 32KB for faster flash programming
set WORKAREASIZE 0x8000
-source [find target/stm32.cfg]
+source [find target/stm32f1x.cfg]
diff --git a/tcl/board/stm3210c_eval.cfg b/tcl/board/stm3210c_eval.cfg
index 27684f0..e069c04 100644
--- a/tcl/board/stm3210c_eval.cfg
+++ b/tcl/board/stm3210c_eval.cfg
@@ -4,4 +4,4 @@
# increase working area to 32KB for faster flash programming
set WORKAREASIZE 0x8000
-source [find target/stm32.cfg]
+source [find target/stm32f1x.cfg]
diff --git a/tcl/board/stm3210e_eval.cfg b/tcl/board/stm3210e_eval.cfg
index 786d027..91807ce 100644
--- a/tcl/board/stm3210e_eval.cfg
+++ b/tcl/board/stm3210e_eval.cfg
@@ -4,7 +4,7 @@
# increase working area to 32KB for faster flash programming
set WORKAREASIZE 0x8000
-source [find target/stm32.cfg]
+source [find target/stm32f1x.cfg]
#
# configure FSMC Bank 1 (NOR/PSRAM Bank 2) NOR flash
diff --git a/tcl/board/stm3220g_eval.cfg b/tcl/board/stm3220g_eval.cfg
index e836f0e..48b57c1 100644
--- a/tcl/board/stm3220g_eval.cfg
+++ b/tcl/board/stm3220g_eval.cfg
@@ -8,4 +8,4 @@ set WORKAREASIZE 0x2
# chip name
set CHIPNAME STM32F207IGT6
-source [find target/stm32f2xxx.cfg]
+source [find target/stm32f2x.cfg]
diff --git a/tcl/target/stm32.cfg b/tcl/target/stm32.cfg
deleted file mode 100644
index 9879c04..000
--- a/tcl/target/stm32.cfg
+++ /dev/null
@@ -1,75 +0,0 @@
-# script for stm32
-
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME stm32
-}
-
-if { [info exists ENDIAN] } {
- set _ENDIAN $ENDIAN
-} else {
- set _ENDIAN little
-}
-
-# Work-area is a space in RAM used for flash programming
-# By default use 16kB
-if { [info exists WORKAREASIZE] } {
- set _WORKAREASIZE $WORKAREASIZE
-} else {
- set _WORKAREASIZE 0x4000
-}
-
-# JTAG speed should be = F_CPU/6. F_CPU after reset is 8MHz, so use F_JTAG =
1MHz
-adapter_khz 1000
-
-adapter_nsrst_delay 100
-jtag_ntrst_delay 100
-
-#jtag scan chain
-if { [info exists CPUTAPID ] } {
- set _CPUTAPID $CPUTAPID
-} else {
- # See STM Document RM0008
- # Section 26.6.3
- set _CPUTAPID 0x3ba00477
[Openocd-development] [PATCH 4/4] flash: add support for deprecated stm32 flash cmds
From: Spencer Oliver ntfr...@users.sourceforge.net
Issue warning when the old cmd is used and redirect to new supported one.
These deprecated cmds will be removed at some point.
Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net
---
src/flash/startup.tcl | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/flash/startup.tcl b/src/flash/startup.tcl
index 6cb7d8e..5f40e64 100644
--- a/src/flash/startup.tcl
+++ b/src/flash/startup.tcl
@@ -1,2 +1,13 @@
# Defines basic Tcl procs for OpenOCD flash module
+# ease migration to updated flash driver
+proc stm32x args {
+ echo DEPRECATED! use 'stm32f1x $args' not 'stm32x $args'
+ eval stm32f1x $args
+}
+
+proc stm32f2xxx args {
+ echo DEPRECATED! use 'stm32f2x $args' not 'stm32f2xxx $args'
+ eval stm32f2x $args
+}
+
--
1.7.0.4
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/4] docs: update to use new stm32 driver names
From: Spencer Oliver ntfr...@users.sourceforge.net
Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net
---
doc/openocd.texi | 29 ++---
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index dfb8e30..069367d 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1277,7 +1277,7 @@ at91sam3u4c.cfg lm3s9b9x.cfg samsung_s3c6410.cfg
at91sam3u4e.cfg lpc1768.cfg sharp_lh79532.cfg
at91sam3uXX.cfg lpc2103.cfg smdk6410.cfg
at91sam7sx.cfg lpc2124.cfg smp8634.cfg
-at91sam9260.cfg lpc2129.cfg stm32.cfg
+at91sam9260.cfg lpc2129.cfg stm32f1x.cfg
c100.cfg lpc2148.cfg str710.cfg
c100config.tcl lpc2294.cfg str730.cfg
c100helper.tcl lpc2378.cfg str750.cfg
@@ -4762,44 +4762,51 @@ applied to all of them.
@end quotation
@end deffn
-@deffn {Flash Driver} stm32x
-All members of the STM32 microcontroller family from ST Microelectronics
+@deffn {Flash Driver} stm32f1x
+All members of the STM32f1x microcontroller family from ST Microelectronics
include internal flash and use ARM Cortex M3 cores.
The driver automatically recognizes a number of these chips using
the chip identification register, and autoconfigures itself.
@example
-flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME stm32f1x 0 0 0 0 $_TARGETNAME
@end example
-Some stm32x-specific commands
-@footnote{Currently there is a @command{stm32x mass_erase} command.
+Some stm32f1x-specific commands
+@footnote{Currently there is a @command{stm32f1x mass_erase} command.
That seems pointless since the same effect can be had using the
standard @command{flash erase_address} command.}
are defined:
-@deffn Command {stm32x lock} num
+@deffn Command {stm32f1x lock} num
Locks the entire stm32 device.
The @var{num} parameter is a value shown by @command{flash banks}.
@end deffn
-@deffn Command {stm32x unlock} num
+@deffn Command {stm32f1x unlock} num
Unlocks the entire stm32 device.
The @var{num} parameter is a value shown by @command{flash banks}.
@end deffn
-@deffn Command {stm32x options_read} num
+@deffn Command {stm32f1x options_read} num
Read and display the stm32 option bytes written by
-the @command{stm32x options_write} command.
+the @command{stm32f1x options_write} command.
The @var{num} parameter is a value shown by @command{flash banks}.
@end deffn
-@deffn Command {stm32x options_write} num (@option{SWWDG}|@option{HWWDG})
(@option{RSTSTNDBY}|@option{NORSTSTNDBY}) (@option{RSTSTOP}|@option{NORSTSTOP})
+@deffn Command {stm32f1x options_write} num (@option{SWWDG}|@option{HWWDG})
(@option{RSTSTNDBY}|@option{NORSTSTNDBY}) (@option{RSTSTOP}|@option{NORSTSTOP})
Writes the stm32 option byte with the specified values.
The @var{num} parameter is a value shown by @command{flash banks}.
@end deffn
@end deffn
+@deffn {Flash Driver} stm32f2x
+All members of the STM32f2x microcontroller family from ST Microelectronics
+include internal flash and use ARM Cortex M3 cores.
+The driver automatically recognizes a number of these chips using
+the chip identification register, and autoconfigures itself.
+@end deffn
+
@deffn {Flash Driver} str7x
All members of the STR7 microcontroller family from ST Microelectronics
include internal flash and use ARM7TDMI cores.
--
1.7.0.4
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rename st32 flash drivers
On 28 July 2011 13:41, Laurent Charpentier laurent_p...@yahoo.com wrote: Hi Spencer, Idea is to bring the stm32 flash drivers inline with their actual names, eg. stm32x to stm32f1x stm32f2xxx to stm32f2x This is a good idea to clean that up. I think you can go one step further by dropping the 'x' (which has no meaning) in order to rename: - stm32x to stm32f1 - stm32f2xxx to stm32f2 I sort of like the x - but the majority rules. Any more votes? Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32F2 flash size detected wrong
On 27 July 2011 00:49, Matthew Lai cyberf...@wecheer.com wrote: Hello! I just started working with a custom PCB STM32F2, and while I got most things to work (including flash and verify), OpenOCD seems to detect the size of flash on my chip wrong. OpenOCD (poll) reports 1024KB, when the chip is a STM32F205RET6, with 512KB flash. The flash size I believe is detected by the driver. Would something bad happen if I go ahead with it, as long as I stay below 512KB? The linker script also has 512KB coded in. Looking at the code the flash size is hard-coded in this driver. ST's infinite wisdom decided to remove the flash size reg on this device - not sure if this will change. We either need to find out of ST have changed this or tweak the driver to allow manual flash bank config. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] rename st32 flash drivers
Hi, Idea is to bring the stm32 flash drivers inline with their actual names, eg. stm32x to stm32f1x stm32f2xxx to stm32f2x This is also getting ready for the new stm32f4x family Any comments? Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] ft2232: Fix configure --with-ftd2xx-linux-tardir
On 12 July 2011 15:01, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Jul 12, 2011 at 9:51 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Try my repo now i have pushed a fix for the warnings. I have just attempted to build under cygwin and get warnings. Seems this patch has broken windows - i am inclined to revert as windows is more likely to use ftd2xx than linux. Looking into the issue i agree with Xiaofan the issue is caused by a change to the wintypes.h old version (0.4.16) typedef unsigned long DWORD; typedef unsigned long ULONG; new version (1.04) typedef unsigned intDWORD; typedef unsigned intULONG; for info long is 8bytes under linux64 - but win64 treats it as 4bytes. I may get more time to look into next week. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] add Fujitsu FM3 Family flash support
On 21/07/2011 19:30, Ronny Strutz wrote: Hi, i've ported the fm3 port by Marc Willam to current git. Feel free to apply. committed to master Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Remove deprecated '-p' option from doc
On 21/07/2011 16:40, Jie Zhang wrote: The subject explains this patch. Jie committed. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Update doc about Jim
On 21/07/2011 16:22, Jie Zhang wrote: The commit log explains this patch. Jie committed. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
On Jul 24, 2011 8:54 PM, Peter Horn peter.h...@bluewin.ch wrote: Hi Tomek Without taking exact measurements, my impression is that the RLink performs about the same with RIDE on Windows and OpenOCD on Linux. FWIW RLink uses the Jungo driver on Windows. Just for info - Jungo is used on winxp and below - vista and newer now use a winusb based driver. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Adding commands for GDB remote accesses
On 21 July 2011 11:18, Igor Skochinsky skochin...@mail.ru wrote: Hello Julius, Thursday, July 21, 2011, 11:48:17 AM, you wrote: JB I'm looking at adding OpenRISC 1000 support to OpenOCD. [skip] JB One solution is we make our GDB port not use these remote query JB commands and instead rely on the register cache fetched with the g JB RSP command. You can have the most used registers in the G/g packet and use P/p for the rest. If you make an XML description (not sure if OpenOCD supports it, but would be nice), you might even not need to rebuild GDB to make use of it. I have wanted to add this support for a while. The first step is that we need to make the target register list dynamic - which is currently fixed. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] add Fujitsu FM3 Family flash support
On 21/07/2011 19:30, Ronny Strutz wrote: Hi, i've ported the fm3 port by Marc Willam to current git. Feel free to apply. As this has no impact on existing functionality i would like to commit this before 0.5 - objections? Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD ticket 34 / usb_bulk_read failed
On 20 July 2011 08:47, Simon Barner bar...@gmx.de wrote: Hi, I can see one change that the referred commit introduced to the ARM-JTAG-EW driver. It is that a speed setting in the init script now actually is executed. Any such setting was previously silently ignored. Do you mean the following in jtag/core.c? + retval = jtag-speed(jtag_speed_var); + if (retval != ERROR_OK) + return retval; The log shows that it is the speed setting that result in the crash. I did some further investigations and noticed the following: When setting the speed in armjtagew_speed(), the length of the outgoing message is obviously 5 not 4 (command + 4 bytes of length information). Getting this right, fixes the error when establishing the JTAG connection. However, when I try to upload an image (size ~50kb), the upload fails with the following error (full log as attachment to the ticket). Debug: 46257 35631 arm-jtag-ew.c:815 armjtagew_usb_read(): armjtagew_usb_read, result = -116 Error: 46258 35631 arm-jtag-ew.c:775 armjtagew_usb_message(): usb_bulk_read failed (requested=1631, result=-116) Error: 46259 35631 arm-jtag-ew.c:717 armjtagew_tap_execute(): armjtagew_tap_execute, wrong result -1, expected 1627 However, when the CMD_SET_TCK_FREQUENCY command is not executed, *and* the subsequent CMD_GET_TCK_FREQUENCY, everything works fine (see patch). The reported JTAG speed is 5867kHz most of the time, sometimes also weird speeds are reported (including negativ ones), so there seems to be a problem with this command, too. The actual speed seems to be slower since flashing the 50kb takes about 80s. The tests where performed using an Olimex ARM-JTAG-EW, firmware version 1.0.6.0, Olimex drivers (=libusb-win32-1.2.2.0), HEAD version of OpenOCD built against libusb-win32-1.2.2.0 on Windows 7/x64. My suggestion is to commit the attached workaround for the 0.5.0 release in order to unbreak the ARM-JTAG-EW, and to investigate on the source of the problems in a second step. I am not keen on committing hacks unless it is the last resort. Does anyone else have one of these dongles that can test the patch? Or look into the problem. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to build openocd with debug symbols (-g)???
On 19 July 2011 03:41, Brian Hutchinson b.hutch...@gmail.com wrote: Hi, I'm not quite sure if my gdb is hosed up or if it is my openocd build. OpenOCD version is Open On-Chip Debugger 0.5.0-dev-00959-gd6c42bf-dirty (2011-07-18-18:35) Is there anything special that needs to be done to build openocd with debug symbols turned on (-g)? When I do a build, I see the -g option being used and I didn't do anything special to turn it on. I'm not an automake expert but I see that in the Makefile CFLAGS has -g set so I guess that is where it is getting it so it looks like debug symbols should be included to me. I'm on a Debian amd64 machine and when I do gdb openocd I get the following output: hutch@neo:~/openocd/openocd/src$ gdb ./openocd GNU gdb (GDB) 7.1 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... /home/hutch/openocd/openocd/src/openocd: not in executable format: File format not recognized (gdb) When I do file I get: hutch@neo:~/openocd/openocd/src$ file ./openocd ./openocd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped So I'm kind of stumped as to what the problem is. Debug info (-g) is on by default. Have a read of the following if using shared libs: http://repo.or.cz/w/openocd.git/blob/HEAD:/BUGS I tend to configure with --disable-shared so you do not run into this sort of problem. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On 18 July 2011 00:46, Steve Bennett ste...@workware.net.au wrote: If there is no way to make automake do this then I guess we have no choice. I have pushed something similar to git. Thanks for doing this, i have tested your changes and are just what we need :) I am going to push the openocd side to complete this fix. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Automatically generate ChangeLog from git log for release tarball
On 17 July 2011 10:18, Luca Bruno lu...@debian.org wrote: make dist should use git2cl to genereate ChangeLog from git history, populating the placeholder file in released tarball. Still not working for srcdir != builddir make[1]: Entering directory `/home/soliver/openocd/openocd-rel' if test -d ../openocd/.git -a \( ! -e openocd-0.5.0-dev/ChangeLog -o -w openocd-0.5.0-dev/ChangeLog \) ; then \ ../openocd/tools/git2cl/git2cl openocd-0.5.0-dev/ChangeLog ; \ fi fatal: Not a git repository (or any of the parent directories): .git Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup and fixes
On 18 July 2011 11:13, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: This patch set fixes some general problems in the RLink interface driver. Most importantly it fixes a performance bug that have been causing decreased throughput. Speed test on a STM32 Primer (STM32F103 platform with built in RLink) with the following openocd.cfg --- great work - someone has been busy :) I have a tendency to leave these patches until after we make a formal 0.5 release - you have some significant changes included. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Jul 15, 2011 3:39 PM, Xiaofan Chen xiaof...@gmail.com wrote: Historical reference back in June 2009. Under Linux, Dominic found no much difference between libftdi and ftd2xx. https://lists.berlios.de/pipermail/openocd-development/2009-June/008846.html My test results support this conclusion under Linux. Under Windows, Freddie found that ftd2xx is significantly faster than libftdi. I will try to use LPC-P2148 to see if that is still the case now. https://lists.berlios.de/pipermail/openocd-development/2009-June/008193.html Tested with a ~29kB image on LPC2103 (upload to flash): libftdi: Start address 0x3c, load size 29640 Transfer rate: 6 KB/sec, 14820 bytes/write. ftd2xx: Start address 0x3c, load size 29640 Transfer rate: 15 KB/sec, 14820 bytes/write. So: libftdi is 2.5x slower Tested with ~114kB image on STM32 (upload to flash): libftdi: Start address 0x8000134, load size 114432 Transfer rate: 8 KB/sec, 16347 bytes/write. ftd2xx: Start address 0x8000134, load size 114432 Transfer rate: 11 KB/sec, 16347 bytes/write. Again slower, this time only about 30%, but still, that's nowhere to comparable On some PC's I even found speed increase when running the jtag dongle through an external powered USB hub. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0-rc2 release
On 14 July 2011 10:05, Luca Bruno lu...@debian.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Christophe PLAGNIOL-VILLARD scrisse: But these are not really a real release, created by make dist. Surely we should be running make dist then uploading the releases to sourceforge/berlios etc. Have you had a look at tools/release.sh? I did, as we have nothing for rc3 I'll use it for the first tarball release and will push the tarball on sf.net if for the rc4 we have nothing again we will post pone it for one week I'm not sure what you're referring to with we have nothing for rc3 (HEAD had progressed since rc2 tag). Anyway, I have two pending patches, already sent for review, regarding real releases (namely populating changelog and avoiding git-describe on tarball). I'd like to hear comments and hopefully get them committed before next rc. Looking at your patches now. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
