Re: [Openocd-development] Mailing list?
On 17 December 2011 16:49, Freddie Chopin 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] Fwd: Delivery Status Notification (Failure)
On 15 December 2011 15:15, Akos Vandra wrote: > -- Forwarded message -- > From: Mail Delivery Subsystem > 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] JimTCL and Fedora RPMs
On 15 December 2011 05:44, Dean Glazeski 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] Google presentation on OpenOCD Gerrit experience
On 2 December 2011 14:12, Laurent Gauch 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 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 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 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] Gerrit with http only
On 2 November 2011 09:24, Øyvind Harboe wrote: > Setting up the commit-msg hook isn't possible using http only: > > scp -p -P 29418 usern...@openocd.zylin.com:hooks/commit-msg .git/hooks/ > > http://repo.or.cz/w/openocd.git/blame?f=HACKING > > Any suggestions? > http://openocd.zylin.com/tools/hooks/commit-msg 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
Re: [Openocd-development] checkpatch enabled
On 29/10/2011 12:38, Antonio Borneo wrote: Hi Spen, I would like to view the parameters passed by jenkins to configure during the build. Are the scripts used by jenkins for OpenOCD available somewhere? --enable-maintainer-mode --enable-ft2232_libftdi --enable-usb_blaster_libftdi --enable-presto_libftdi --enable-usbprog --enable-jlink --enable-vsllink --enable-rlink --enable-ulink --enable-arm-jtag-ew --enable-buspirate --enable-dummy I have also tweaked the build script to echo the args used: http://openocd.zylin.com/jenkins/job/openocd/lastBuild/consoleFull 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 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
[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] 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] 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] 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] gerrit comments as mail?
On 26 October 2011 13:35, Attila Kinali 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] adding checkpatch to code review on jenkins
On Oct 25, 2011 8:34 AM, "Øyvind Harboe" 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
Re: [Openocd-development] Command-line paths problem in Windows
On 21 October 2011 12:40, freddie_chopin wrote: > W dniu 2011-10-21 13:06:05 użytkownik Spencer Oliver > 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] Command-line paths problem in Windows
On 20 October 2011 17:04, Freddie Chopin 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
[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] gitweb down?
On 20 October 2011 12:06, Spencer Oliver wrote: > On 20 October 2011 11:49, Uwe Hermann 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] gitweb down?
On 20 October 2011 11:49, Uwe Hermann 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] Change in openocd[master]: jlink libusb1 driver with libusb1 common driver interface.
On 19 October 2011 16:38, Mauro Gamba wrote: > Sorry for patch errors. > I started to patch the jlink driver to use libusb-1 because libusb-0 > is not developed further. > I haven't done speed tests until now. > http://openocd.zylin.com/33 adds libusb-1.0 support to the jlink. Just wondering if anyone had any input on this ? 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 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 >> --- >> 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]: 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 --- 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 ___ 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 --- 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 ___ 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 --- 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 ___ 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 --- 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 ___ 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 --- 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 ___ 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 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]: 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 --- 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 Gerrit-Reviewer: Spencer Oliver ___ 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] OpenOCD Gerrit Review
On 11 October 2011 13:40, Spencer Oliver 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
[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] Show of hands for/against gerrit
On Oct 6, 2011 10:01 PM, "Øyvind Harboe" 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 wrote: > On Tue, Oct 4, 2011 at 1:26 PM, Spencer Oliver 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" wrote: > FYI, > > My first instinct is to move the mailing list wholesale to sourceforge. > > > -- Forwarded message -- > From: > 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=2055&group_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=2056&group_id=2 > > Fraunhofer
Re: [Openocd-development] EN29LV800BB CFI Patch for OpenOCD
On 18 August 2011 09:02, Gunnar Henne wrote: > Hello, > > here is a patch to support EN29LV800BB flash devices via CFI. I have > successfully tested ist in openocd 0.5.0 with the hardware described here: > http://www.bettyhacks.com > > It was posted by telek...@gmx.de in the bettyhacks forum for openocd > 0.4.0 and integrated into 0.5.0 by me. > > Kind regards, > > Gunnar Henne > Many Thanks, i will commit Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Versaloon driver update fix, and about jtag_usb_open
On 11 July 2011 19:03, simon qian wrote: > Is this attached patch OK? > > About SWD support, I can check the current OpenOCD code today > and provide a todo list according to my OpenOCD swd patch which > has been tested for a long time. > > 2011/7/11 simon qian >> >> OK, I'll try fix it soon. >> >> 2011/7/11 Peter Stuge >>> >>> simon qian wrote: >>> > Attachment is the versaloon driver update, please commit if no problem. >>> >>> Thanks! i will commit i hear no objections 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 wrote: > On 16/08/2011, at 8:32 PM, Spencer Oliver wrote: > >> On 16 August 2011 11:13, Spencer Oliver wrote: >>> On 16 August 2011 11:03, Steve Bennett wrote: >>>> On 12/08/2011, at 11:12 PM, Xiaofan Chen wrote: >>>> >>>>> On Wed, Aug 10, 2011 at 3:39 PM, Xiaofan Chen wrote: >>>>>> On Wed, Aug 10, 2011 at 3:34 PM, Olivier Schonken >>>>>> 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 23:21, Andreas Fritiofson
wrote:
>
>
> On Mon, Aug 15, 2011 at 5:03 PM, Jie Zhang wrote:
>>
>> On Mon, Aug 15, 2011 at 9:35 AM, Spencer Oliver
>> wrote:
>> > On 15 August 2011 14:22, Eric Wetzel 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!
>>
>> Jie
>
> > +if test -f $srcdir/guess-rev.sh ; then
> Great, but you should probably check if it's executable instead of just a
> regular file.
> /Andreas
>
true, feel free to update
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:13, Spencer Oliver wrote: > On 16 August 2011 11:03, Steve Bennett wrote: >> On 12/08/2011, at 11:12 PM, Xiaofan Chen wrote: >> >>> On Wed, Aug 10, 2011 at 3:39 PM, Xiaofan Chen wrote: >>>> On Wed, Aug 10, 2011 at 3:34 PM, Olivier Schonken >>>> 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 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:03, Steve Bennett wrote: > On 12/08/2011, at 11:12 PM, Xiaofan Chen wrote: > >> On Wed, Aug 10, 2011 at 3:39 PM, Xiaofan Chen wrote: >>> On Wed, Aug 10, 2011 at 3:34 PM, Olivier Schonken >>> 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] [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] [PATCH] A fix (was Re: Git revision string missing from banner)
On 15 August 2011 16:03, Jie Zhang wrote:
> On Mon, Aug 15, 2011 at 9:35 AM, Spencer Oliver wrote:
>> On 15 August 2011 14:22, Eric Wetzel 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] Git revision string missing from banner
On 15 August 2011 14:22, Eric Wetzel wrote:
> Hello,
>
> Recently, perhaps the last month or two, I've noticed the Git revision
> string is not being appended to base version in the OpenOCD banner.
> From my investigation, I believe that my observation of the problem
> was dependent upon my use of a new toolchain and environment, because
> the suspect lines seem to have been there for quite some time.
>
> I'm using the (new, as of about 2 months ago) mingw cross-compiler
> under Cygwin in Windows 7. `configure` seems to think that I'm trying
> to build a release, so it doesn't run guess-rev.sh. I found this in
> configure.in:
> 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)
>
> AC_MSG_CHECKING([whether to build a release])
> if test $has_guess_rev = no; then
> build_release=yes
> else
> build_release=no
> fi
> AC_MSG_RESULT($build_release)
> else
> build_release=yes
> fi
>
> 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
>
> Before someone reminded me of the --build and --host options in
> configure, I would append CC='gcc-3 -mno-cygwin' to the configure
> line. Perhaps this fooled the process into thinking that it wasn't
> cross-compiling.
>
I spotted this a while back but have never found time to look into further.
But you are correct and this is an issue with cross compiling mingw
under cygwin.os.
It is not so much the files existence, but we must be able to execute it.
As you also point out the old method did fool the build system into
thinking it was a native build.
However it is still an issue for example 32bit builds on a 64bit host.
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" wrote: > > On Sat, Aug 13, 2011 at 9:38 AM, Jie Zhang wrote: > > On Fri, Aug 12, 2011 at 9:27 PM, Xiaofan Chen 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=sourcenames&keywords=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 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] [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 Fritiofson 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] Openocd | Doubts regarding
On 11 August 2011 09:18, Karthick Anand wrote: > Hello, > > I would like to introduce myself as Karthick working as a Design Engineer in > Kalycito Info tech,Coimbatore.Now i am working in STM32 Micro controller,for > that i need to debug it via ST-Link/V2/01-0 adapter.Is this "Openocd" will > support ST-Link adapter? > > Kindly give me the information, > stlink is not supported by openocd - it required some major tweaks that i did not have time for. There are some other efforts to get the stlink working: https://github.com/whitequark/stlink http://www.andrewsteadman.ca/myprojects/projects/stmdiscovery you can also reprogram it as a versaloon: http://www.versaloon.com/bbs/viewtopic.php?p=74#p74 I have not seen any support for the stlink/v2 yet as this uses a different usb class than the v1. 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/08/2011 14:41, Jie Zhang wrote: On Wed, Aug 10, 2011 at 9:29 AM, Xiaofan Chen wrote: On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver 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 MinGW configure failure
On 10 August 2011 13:26, Xiaofan Chen wrote: > On Tue, Aug 9, 2011 at 11:11 PM, Spencer Oliver wrote: >> On 9 August 2011 16:01, Xiaofan Chen wrote: >>> On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver >>> 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 August 2011 13:30, Xiaofan Chen wrote: > On Wed, Aug 10, 2011 at 6:35 PM, Spencer Oliver wrote: >> On 10 August 2011 11:15, Steve Bennett 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 11:15, Steve Bennett wrote: > On 10/08/2011, at 6:39 PM, Spencer Oliver wrote: > >> On 10 August 2011 07:11, Steve Bennett wrote: >>> On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: >>> >>>> On Wed, Aug 10, 2011 at 11:44 AM, Steve Bennett >>>> 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 07:11, Steve Bennett wrote: > On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: > >> On Wed, Aug 10, 2011 at 11:44 AM, Steve Bennett >> 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] rebase vs. merge
On 10 August 2011 09:13, Øyvind Harboe 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] [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] 0.5.0 MinGW configure failure
On 9 August 2011 16:11, Spencer Oliver wrote: > On 9 August 2011 16:01, Xiaofan Chen wrote: >> On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver 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] 0.5.0 MinGW configure failure
On 9 August 2011 16:01, Xiaofan Chen wrote: > On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver 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 15:10, Xiaofan Chen wrote: > On Tue, Aug 9, 2011 at 10:05 PM, Xiaofan Chen wrote: >> On Tue, Aug 9, 2011 at 9:47 PM, Xiaofan Chen wrote: >>> On Tue, Aug 9, 2011 at 9:27 PM, Spencer Oliver 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 14:34, Xiaofan Chen wrote: > On Tue, Aug 9, 2011 at 9:25 PM, Spencer Oliver wrote: >> On 9 August 2011 13:48, Vit Mares 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 14:13, Jie Zhang wrote: > On Tue, Aug 9, 2011 at 7:52 AM, Vit Mares 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 13:48, Vit Mares 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 12:52, Vit Mares 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 release
On 9 August 2011 10:31, Tomek CEDRO wrote: > On Tue, Aug 9, 2011 at 8:53 AM, Jean-Christophe PLAGNIOL-VILLARD > 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] Tags
On 5 August 2011 11:07, Øyvind Harboe 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] Tags
On 5 August 2011 10:39, Andreas Fritiofson wrote: > > > On Fri, Aug 5, 2011 at 11:26 AM, Spencer Oliver > 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 10:26, Spencer Oliver wrote: > On 5 August 2011 10:19, Andreas Fritiofson > wrote: >> >> >> On Fri, Aug 5, 2011 at 11:02 AM, Spencer Oliver >> wrote: >>> >>> On 5 August 2011 09:58, Andreas Fritiofson >>> wrote: >>> > >>> > >>> > On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe >>> > 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:19, Andreas Fritiofson wrote: > > > On Fri, Aug 5, 2011 at 11:02 AM, Spencer Oliver > wrote: >> >> On 5 August 2011 09:58, Andreas Fritiofson >> wrote: >> > >> > >> > On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe >> > 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 09:58, Andreas Fritiofson wrote: > > > On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe > 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] Last call before release
On 5 August 2011 04:38, Rodrigo Rosa 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] [PATCH] arm11: disable broken optimization for setting current scan chain
On 5 August 2011 09:00, Øyvind Harboe 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] Tags
On 5 August 2011 07:56, Øyvind Harboe 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] Automatically generate ChangeLog from git log for release tarball
On 3 August 2011 15:00, Andreas Fritiofson wrote: > > > On Wed, Aug 3, 2011 at 12:28 PM, Luca Bruno 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] [PATCH] Automatically generate ChangeLog from git log for release tarball
On 3 August 2011 11:46, Spencer Oliver wrote: > On 3 August 2011 11:28, Luca Bruno 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 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 Signed-off-by: Spencer Oliver --- 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 11:28, Luca Bruno 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] Luminary config script patch
On 2 August 2011 03:05, B 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] Reset fails LM3S Tempest C5 due to failure to read device class
On 1 August 2011 16:16, B wrote: > Spen: > > Thanks. I got it to work based on looking at the PIC32 configuration. Maybe > not the neatest way but it will work. > > How do I best contribute the changes to the trunk? > > The modified configuration file is attached. > http://openocd.berlios.de/doc/doxygen/html/index.html ___ 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
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
---
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] Better fixes for set but not used warnings
On 29 July 2011 16:54, Jie Zhang wrote: > On Fri, Jul 29, 2011 at 11:41 AM, Spencer Oliver wrote: >> On 29 July 2011 15:32, Jie Zhang 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
Re: [Openocd-development] Reset fails LM3S Tempest C5 due to failure to read device class
On 30 July 2011 22:48, B 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 3/3] ft2232: Add casts to avoid warnings
On 29 July 2011 22:23, Andreas Fritiofson 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] [PATCH 3/4] cfg: update scripts to use new stm32 driver names
On 29 July 2011 16:56, Andreas Fritiofson wrote: > > > On Fri, Jul 29, 2011 at 5:38 PM, Spencer Oliver > wrote: >> >> On 29 July 2011 15:43, Andreas Fritiofson >> 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
Re: [Openocd-development] [PATCH] Better fixes for set but not used warnings
On 29 July 2011 15:32, Jie Zhang 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. 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 15:43, Andreas Fritiofson 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 14:54, Andreas Fritiofson wrote: > > On Thu, Jul 28, 2011 at 1:52 PM, Spencer Oliver > 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] script vs source
On 29 July 2011 11:45, Jie Zhang 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 4/4] flash: add support for deprecated stm32 flash cmds
On 29 July 2011 02:01, Steve Bennett 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] GDB always executes code on the first declared target in a multi-target configuration
On 28 July 2011 15:23, Drasko DRASKOVIC wrote: > Hi all, > I have a multicore SoC, and I use "target create" command to create > several targets, one for each CPU. > > Main CPU is mentioned first. > > When I want to load and execute Linux kernel on secondary CPU, I use > "mon targets second" to switch to the second target from within GDB, > and then I do "load" to load kernel to SDRAM of my remote target. At > this moment I have OpenOCD complaining about work area, although I had > defined working area for the secondary (but not primary) CPU. > > That means that code load is executed by the primary CPU, and not > secondary as I thought, because I can see tha OpenOCD keeps star on > second target, marking this one as active. > > Also, once the code is loaded it is executed on the primary CPU. How > come ? And why the OpenOCD is marking that second CPU is the active > target ? > > How to force GDB to use second target in a multi-target configuration, > and not always the first declared by the "target create" command ? > It has been a while since i tested openocd with multiple targets - over a year at a guess. Hard to give an answer, but if i get a chance i will run some test tomorrow. Cheers Spen ___ 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 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
[Openocd-development] [PATCH 2/4] docs: update to use new stm32 driver names
From: Spencer Oliver
Signed-off-by: Spencer Oliver
---
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
[Openocd-development] [PATCH 4/4] flash: add support for deprecated stm32 flash cmds
From: Spencer Oliver
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
---
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]rename stm32 flash drivers
[PATCH 1/4] flash: update stm32 driver names [PATCH 2/4] docs: update to use new stm32 driver names [PATCH 3/4] cfg: update scripts to use new stm32 driver names [PATCH 4/4] flash: add support for deprecated stm32 flash cmds 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 3/4] cfg: update scripts to use new stm32 driver names
From: Spencer Oliver
Signed-off-by: Spencer Oliver
---
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
-}
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture
[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] STM32F2 flash size detected wrong
On 27 July 2011 00:49, Matthew Lai 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
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
