Re: [Openocd-development] Command-line paths problem in Windows
W dniu 2011-10-21 00:12:52 użytkownik Andrew Leech
napisał:
> Have you tried with double backslash "\\" ?
Actually no, I guess that it would probably work but you'd still have to give
path to OpenOCD working directory in Eclipse and probably still use "..\\"
before directory with config file. Anyway - it worked in some way before, it's
said in the manual to use it that way ("-f target/sth.cfg") so I guess that it
would be best to restore previous - very convenient - behavior.
4\/3!!
___
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] commit - jim-nvp is moving from jimtcl to openocd
On Fri, Oct 21, 2011 at 10:13 AM, Spencer Oliver wrote: > with ref to subject commit ef885d3b2a3001325f525df250dadd570e5d743e > the files jim-nvp.[ch] have no copyright info. They are FreeBSD, but when combined with OpenOCD source, they have to be distributed under GPL of course. The header can say FreeBSD though. Copy header from Jim project. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: 48bbfa4 jim: add missing jim license
This is an automated email from Gerrit. Spencer Oliver (s...@spen-soft.co.uk) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/39 -- gerrit commit 48bbfa4ea38ad0acbc64a52c40619f8dba29a9c7 Author: Spencer Oliver Date: Fri Oct 21 09:51:21 2011 +0100 jim: add missing jim license Change-Id: Ib8e34739d92cd54655b9b47d07b856a82ff25f3c Signed-off-by: Spencer Oliver diff --git a/src/helper/jim-nvp.c b/src/helper/jim-nvp.c index be94f15..6a78a84 100644 --- a/src/helper/jim-nvp.c +++ b/src/helper/jim-nvp.c @@ -1,3 +1,46 @@ +/* Jim - A small embeddable Tcl interpreter + * + * Copyright 2005 Salvatore Sanfilippo + * Copyright 2005 Clemens Hintze + * Copyright 2005 patthoyts - Pat Thoyts + * Copyright 2008 oharboe - Ãyvind Harboe - oyvind.har...@zylin.com + * Copyright 2008 Andrew Lunn + * Copyright 2008 Duane Ellis + * Copyright 2008 Uwe Klein + * Copyright 2008 Steve Bennett + * Copyright 2009 Nico Coesel + * Copyright 2009 Zachary T Welch z...@superlucidity.net + * Copyright 2009 David Brownell + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above + *copyright notice, this list of conditions and the following + *disclaimer in the documentation and/or other materials + *provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE JIM TCL PROJECT ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, + * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A + * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * JIM TCL PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF + * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * The views and conclusions contained in the software and documentation + * are those of the authors and should not be interpreted as representing + * official policies, either expressed or implied, of the Jim Tcl Project. + */ + #include #include diff --git a/src/helper/jim-nvp.h b/src/helper/jim-nvp.h index 12ff889..4428f5d 100644 --- a/src/helper/jim-nvp.h +++ b/src/helper/jim-nvp.h @@ -1,3 +1,46 @@ +/* Jim - A small embeddable Tcl interpreter + * + * Copyright 2005 Salvatore Sanfilippo + * Copyright 2005 Clemens Hintze + * Copyright 2005 patthoyts - Pat Thoyts + * Copyright 2008 oharboe - Ãyvind Harboe - oyvind.har...@zylin.com + * Copyright 2008 Andrew Lunn + * Copyright 2008 Duane Ellis + * Copyright 2008 Uwe Klein + * Copyright 2008 Steve Bennett + * Copyright 2009 Nico Coesel + * Copyright 2009 Zachary T Welch z...@superlucidity.net + * Copyright 2009 David Brownell + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above + *copyright notice, this list of conditions and the following + *disclaimer in the documentation and/or other materials + *provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE JIM TCL PROJECT ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, + * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A + * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * JIM TCL PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF + * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * The views and conclusions contained in the software and documentation + * are those of the authors and should not be interpreted as representing + * official policies, either expressed or implied, of the Jim Tcl Project. + */ + #ifndef JIM_NVP_H #define JIM_NVP_H -- ___ Openocd-development mailing list Openocd-de
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
Re: [Openocd-development] Command-line paths problem in Windows
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? 4\/3!! ___ 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
W dniu 2011-10-21 13:50:26 użytkownik Spencer Oliver napisał: > you could either do a git bisect to see what version it broke at. Will bisecting also affect jimtcl version used as a submodule or maybe always the most recent one is used? Generally I see some changes that could affect path handling so I'll give it a try in the afternoon. 4\/3!! ___ 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.
Mauro Gamba wrote: > I think to proceed in this way: > > - Add to the configuration step the possibility to choose which usb > library to use. Use pkg-config to check for all libraries that can work, and use with the first one that is found. Check for libusb-1.0 first. You will need to study more autoconf than you needed before. You can of course also ask on the list if you are uncertain about something. > - Create an abstraction layer to the usb library with all the > necessary functions for the drivers. Yes and no. "all the neccessary functions" should not be created at once. Start with an abstraction layer that works for one driver but still allows upward compatibility with the other drivers. This may be more difficult than you think. You will have to analyze each driver more in depth, and I guess it will take a bit of time. The above two items shall be in the first commit. Please do not wait for the complete driver analysis before you make the commit, please start with creating an abstraction layer that is sufficient for only one driver, push that to Gerrit, and see what the feedback is. This is OK to do even if you want to do more work on the commit, but it is important to get review feedback early, so that you do not have to do double work. Of course, remember to pay close attention to simple details like checking all possible errors and code style. > - Modify the drivers to use the abstraction layer instead directly > the library. > > Do you think it's reasonable? Yes, but it is more work and more complicated, so it is even more important than before to only start small and then gather feedback. Thanks again for working on this! I'm really looking forward to your commits! //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit background
Xiaofan Chen wrote: > >> "+1 Looks good to me, but someone else must approve > >> 0 No score > >> -1 I would prefer that you didn't submit this" > >> > >> If the contributor see a -1 and refer to the above, > >> I do not think it is that encouraging. :-). Do you already consider that "submit" is the Gerrit term for adding a change into the public repository; in the above it does *not* refer to the contributor sending the change into Gerrit? The text in the labels is what a reviewer is saying to the project, ie. maintainers. What the reviewer is saying to the contributor is the text written as comments both inline within the change and in the general comment field during review. I think the wording makes sense when keeping in mind the terminology and who the receiver of the different pieces of information is, but I do agree that the text labels could be made more clear. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clang static analyzer
Hmm It doesn't work here. Any tips? Where does the output go? scan-build ./configure --enable-maintainer-mode --enable-dummy --disable-werror scan-build make ... make[2]: Leaving directory `/home/oyvind/openocd' make[1]: Leaving directory `/home/oyvind/openocd' scan-build: Removing directory '/tmp/scan-build-2011-10-21-1' because it contains no reports. This is with Ubuntu. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ 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 Fri, Oct 21, 2011 at 7:06 PM, Spencer Oliver wrote: > On 20 October 2011 17:04, Freddie Chopin wrote: >> 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. > I can reproduce the issue with the latest git, build under Windows with MinGW/MSys. For version 0.5.0, the following two commands work and I use only either of them. openocd.exe -f board\ek-lm3s1968.cfg openocd.exe -f board/ek-lm3s1968.cfg For latest git, none of the following commands work. openocd.exe -f board\ek-lm3s1968.cfg openocd.exe -f board/ek-lm3s1968.cfg openocd.exe -f board\\ek-lm3s1968.cfg openocd.exe -f board//ek-lm3s1968.cfg openocd.exe -f ..\board\ek-lm3s1968.cfg Example running log. C:\work\openocd\binary\bin>openocd.exe -f board//ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Runtime Error: embedded:startup.tcl:58: couldn't read file "C:workopenocinarin.. /board//ek-lm3s1968.cfg": No such file or directory in procedure 'script' at file "embedded:startup.tcl", line 58 C:\work\openocd\binary\bin>openocd.exe -f ..\board\ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Runtime Error: embedded:startup.tcl:58: couldn't read file ".oardek-lm3s1968.cfg ": No such file or directory in procedure 'script' at file "embedded:startup.tcl", line 58 > Double backslash seems to fix it. That helps. The following commands work. openocd.exe -f ..\\board\\ek-lm3s1968.cfg openocd.exe -f ..//board//ek-lm3s1968.cfg The following command also works. openocd.exe -f ../board/ek-lm3s1968.cfg -- Xiaofan ___ 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
Xiaofan Chen wrote: > For version 0.5.0, the following two commands work and I use only > either of them. > openocd.exe -f board\ek-lm3s1968.cfg > openocd.exe -f board/ek-lm3s1968.cfg > > For latest git, none of the following commands work. > openocd.exe -f board\ek-lm3s1968.cfg > openocd.exe -f board/ek-lm3s1968.cfg The first is understandable, but the second not working may be a real problem. > Example running log. When looking for string parsing errors it's critical that every byte of log output is unchanged. I think some lines were wrapped in the email, most likely by some email software. This makes debugging impossible. Perhaps you can direct output to a text file and attach it to an email? > C:\work\openocd\binary\bin>openocd.exe -f board//ek-lm3s1968.cfg > Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.sourceforge.net/doc/doxygen/bugs.html > Runtime Error: embedded:startup.tcl:58: couldn't read file > "C:workopenocinarin.. > /board//ek-lm3s1968.cfg": No such file or directory > in procedure 'script' > at file "embedded:startup.tcl", line 58 So the commit that broke this is probably commit a62d8f2271312ba955e839509590f5a5975b1b49 Author: Steve Bennett Date: Thu Aug 11 12:10:54 2011 +1000 Evaluate 'script' in the global scope Scripts sourced via 'script' should evaluate in the global scope to make it easy to set and reference global variables. Signed-off-by: Steve Bennett You could test by running: git checkout -b beforesuspect a62d8f22^ In the git dir. This creates a branch called beforesuspect which points to the commit preceding Steve's. Then build as usual. (make distclean or so.) If you then want to test that this commit created the problem then you can run: git checkout -b suspect a62d8f22 Which creates a branch called suspect, that points to Steve's commit. Clean and build again. When done, go back to the master branch, and clean up the temporary ones: git checkout master git branch -d beforesuspect git branch -d suspect > > Double backslash seems to fix it. > > That helps. The following commands work. > openocd.exe -f ..\\board\\ek-lm3s1968.cfg I guess the uplevel makes the parameter be evaluated by the interpreter, meaning that all \ is unescaped. > openocd.exe -f ..//board//ek-lm3s1968.cfg > > The following command also works. > openocd.exe -f ../board/ek-lm3s1968.cfg So there are two differences in behavior versus 0.5: 1. \ in -f parameters get evaluated one time extra by Jim tcl 2. paths in -f parameters are now relative to a different directory, one level down from previously 2. is most likely caused by another commit. //Peter ___ 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
Peter Stuge wrote:
> > C:\work\openocd\binary\bin>openocd.exe -f board//ek-lm3s1968.cfg
> > Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26)
> > Licensed under GNU GPL v2
> > For bug reports, read
> > http://openocd.sourceforge.net/doc/doxygen/bugs.html
> > Runtime Error: embedded:startup.tcl:58: couldn't read file
> > "C:workopenocinarin..
> > /board//ek-lm3s1968.cfg": No such file or directory
> > in procedure 'script'
> > at file "embedded:startup.tcl", line 58
>
> So the commit that broke this is probably
>
> commit a62d8f2271312ba955e839509590f5a5975b1b49
By the way, here is how I found this:
$ git grep -n proc.script|cat
src/helper/startup.tcl:57:proc script {filename} {
$ git blame -L 57,59 src/helper/startup.tcl|cat
3287b866 src/startup.tcl(oharboe 2008-07-16 20:20:15 + 57)
proc script {filename} {
a62d8f22 src/helper/startup.tcl (Steve Bennett 2011-08-11 12:10:54 +1000 58)
uplevel #0 source [find $filename]
3287b866 src/startup.tcl(oharboe 2008-07-16 20:20:15 + 59) }
And I confirmed that the commit was not in 0.5.0:
$ git tag --contains a62d8f22
$
Of course it is still possible that some other commit is the real
problem! But the uplevel name and the perfect commit message makes
it easy to guess that this change is responsible for the extra
evaluation.
//Peter
___
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 Fri, Oct 21, 2011 at 11:06 PM, Peter Stuge wrote: > So there are two differences in behavior versus 0.5: > > 1. \ in -f parameters get evaluated one time extra by Jim tcl > 2. paths in -f parameters are now relative to a different directory, > one level down from previously > > 2. is most likely caused by another commit. Yes you are right. I moved openocd.exe out of bin directory to make it in the same directory of the scripts files (board, interface, etc) and 2 will go away. C:\work\openocd\binary>openocd -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz ... The other command used to work for version 0.5.0 still does not work. C:\work\openocd\binary>openocd -f board\ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Runtime Error: embedded:startup.tcl:58: couldn't read file "boardek-lm3s1968.cfg": No such file or directory in procedure 'script' at file "embedded:startup.tcl", line 58 -- Xiaofan ___ 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 Fri, Oct 21, 2011 at 11:37 PM, Xiaofan Chen wrote: > On Fri, Oct 21, 2011 at 11:06 PM, Peter Stuge wrote: >> So there are two differences in behavior versus 0.5: >> >> 1. \ in -f parameters get evaluated one time extra by Jim tcl >> 2. paths in -f parameters are now relative to a different directory, >> one level down from previously >> >> 2. is most likely caused by another commit. > > Yes you are right. I moved openocd.exe out of bin directory to > make it in the same directory of the scripts files (board, interface, etc) > and 2 will go away. > C:\work\openocd\binary>openocd -f board/ek-lm3s1968.cfg > Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.sourceforge.net/doc/doxygen/bugs.html > Info : only one transport option; autoselect 'jtag' > 500 kHz > ... > > The other command used to work for version 0.5.0 still does not work. > > C:\work\openocd\binary>openocd -f board\ek-lm3s1968.cfg > Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.sourceforge.net/doc/doxygen/bugs.html > Runtime Error: embedded:startup.tcl:58: couldn't read file > "boardek-lm3s1968.cfg": No such file or directory > in procedure 'script' > at file "embedded:startup.tcl", line 58 > The following does work now. C:\work\openocd\binary>openocd -f board\\ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz ... -- Xiaofan ___ 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
Xiaofan Chen wrote: > The following does work now. > C:\work\openocd\binary>openocd -f board\\ek-lm3s1968.cfg -f has not changed in almost 5 years, and directly calls the script procedure, which was changed by Steve's commit. So maybe both things are caused by the commit after all. There's actually an easier way to test further, without creating branches, since the commit only changes interpreted code nothing needs to be recompiled. Edit src/startup.tcl (note! not the file that the commit changes, the commit changes src/helper/startup.tcl, if that file is changed then rebuild is neccessary) and remove uplevel #0 from line 58. The line should only read: source [find $filename] This is the functional equivalent of reverting Steve's commit. I am not proposing that we do this, but it helps understanding this code better. FWIW I like very much that -f in current git is using paths relative to the directory where openocd is being run. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clang static analyzer
On 10/21/2011 10:40 AM, Øyvind Harboe wrote: Where does the output go? It should go in a directory named scan-build--MM-DD-n/, where n starts from 1. If I recall correctly, that directory ended up in the directory I ran scan-build from. scan-build ./configure --enable-maintainer-mode --enable-dummy --disable-werror scan-build make ... make[2]: Leaving directory `/home/oyvind/openocd' make[1]: Leaving directory `/home/oyvind/openocd' scan-build: Removing directory '/tmp/scan-build-2011-10-21-1' because it contains no reports. I got the same "contains no reports" after ./configure (which makes some sense), but not after make. I ran it on Ubuntu 10.04 with LLVM and Clang from source, using the instructions in the section "On Unix-like Systems" here: http://clang.llvm.org/get_started.html#build I also configured with --enable-maintainer-mode only. Perhaps to start you can try that and see if you get a report? Marti ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: 7067428 Revert "Evaluate 'script' in the global scope"
This is an automated email from Gerrit.
Freddie Chopin (freddie.cho...@gmail.com) just uploaded a new patch set to
Gerrit, which you can find at http://openocd.zylin.com/40
-- gerrit
commit 70674284abe1e4106f5b06829a9f8f2f000a3977
Author: Freddie Chopin
Date: Fri Oct 21 18:20:17 2011 +0200
Revert "Evaluate 'script' in the global scope"
This reverts commit a62d8f2271312ba955e839509590f5a5975b1b49. This caused
Windows builds behave differently than before because backslash from paths
got
unescaped and effectively wiped out. Configs could only be passed with "-f
../dir/config.cfg" or "-f ..\\dir\\config.cfg" instead of usual "-f
dir/config.cfg" (or using backslash) as previously.
Change-Id: I13b4abac6dbe6d770cc11a4e61c9421ef340da83
Signed-off-by: Freddie Chopin
diff --git a/src/helper/startup.tcl b/src/helper/startup.tcl
index e2ea27d..2e2982c 100644
--- a/src/helper/startup.tcl
+++ b/src/helper/startup.tcl
@@ -53,9 +53,9 @@ proc find {filename} {
add_usage_text find ""
add_help_text find "print full path to file according to OpenOCD search rules"
-# Find and run a script
+# Run script
proc script {filename} {
- uplevel #0 source [find $filename]
+ source [find $filename]
}
add_help_text script "filename of OpenOCD script (tcl) to run"
add_usage_text script ""
--
___
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
Just as Peter suspected the problem is caused by commit a62d8f2271312ba955e839509590f5a5975b1b49. I've verified that with bisecting. I've also build version with that single commit reverted which worked as expected and as before. I've pushed revert-patch for Gerrit review. I believe it should be reverted for now but the general idea it introduced (easing use of global variables) is worth implementing but in some other way. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clang static analyzer
I upgraded to Ubuntu 11.10 from Ubuntu 11.04 and now it works :-) Looks like this is bleeding edge stuff... -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: 7405d98 clang: fix malloc() warning with assert
This is an automated email from Gerrit.
Ãyvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to
Gerrit, which you can find at http://openocd.zylin.com/41
-- gerrit
commit 7405d985b1957c6dfbde3cdf5842bfad914f2873
Author: Ãyvind Harboe
Date: Fri Oct 21 19:00:09 2011 +0200
clang: fix malloc() warning with assert
Change-Id: I989d2655622a9f11f4a0a2994014e42822587ecd
Signed-off-by: Ãyvind Harboe
diff --git a/src/jtag/tcl.c b/src/jtag/tcl.c
index 3b2f83b..468edf5 100644
--- a/src/jtag/tcl.c
+++ b/src/jtag/tcl.c
@@ -172,6 +172,7 @@ static int Jim_Command_drscan(Jim_Interp *interp, int argc,
Jim_Obj *const *args
}
num_fields = (argc-2)/2;
+ assert(num_fields > 0);
fields = malloc(sizeof(struct scan_field) * num_fields);
for (i = 2; i < argc; i += 2)
{
diff --git a/src/target/image.c b/src/target/image.c
index 21ce11f..8f437c0 100644
--- a/src/target/image.c
+++ b/src/target/image.c
@@ -473,6 +473,8 @@ static int image_elf_read_headers(struct image *image)
if ((field32(elf, elf->segments[i].p_type) == PT_LOAD) &&
(field32(elf, elf->segments[i].p_filesz) != 0))
image->num_sections++;
+ assert(image->num_sections > 0);
+
/**
* some ELF linkers produce binaries with *all* the program header
* p_paddr fields zero (there can be however one loadable segment
--
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: d5d891e clang: fix warning w/assert so that clang knows that there will be no division by zero
This is an automated email from Gerrit. Ãyvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/42 -- gerrit commit d5d891eaeff5c4484b2858e90ece1f2ce312c097 Author: Ãyvind Harboe Date: Fri Oct 21 19:14:57 2011 +0200 clang: fix warning w/assert so that clang knows that there will be no division by zero Change-Id: I98ac62a22f21043bb535a667a4f1f1537ccde2a4 Signed-off-by: Ãyvind Harboe diff --git a/src/target/target.c b/src/target/target.c index b68eee3..d4cb577 100644 --- a/src/target/target.c +++ b/src/target/target.c @@ -3317,7 +3317,8 @@ static void writeGmon(uint32_t *samples, uint32_t sampleNum, const char *filenam } } - int addressSpace = (max-min + 1); + int addressSpace = (max - min + 1); + assert(addressSpace >= 2); static const uint32_t maxBuckets = 16 * 1024; /* maximum buckets. */ uint32_t length = addressSpace; -- ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New patch to review for openocd: 7067428 Revert "Evaluate 'script' in the global scope"
On 2011-10-21 19:09, Øyvind Harboe (Code Review) wrote: > Please look up the discussion of why this code was modified to use > uplevel and amend the commit with an explanation of why we should use > the proposed behaviour instead. I cannot comment on Gerrit... The discussion - https://lists.berlios.de/pipermail/openocd-development/2011-August/020462.html - not easy to find (links to list are links to NEW and EMPTY sourceforge forum) so I had to google that up. There is absolutely no discussion or reasoning there, this change was introduced "just because" and based on "why not?". Or maybe there's another discussion I cannot find. The commit message I've made has an explanation of why the change was reverted. Or maybe a change in behavior for Windows users is not a reason to revert a patch that introduced it by mistake? To reiterate - now OpenOCD does NOT work as manual says. This is a change in behavior that did not ever change and never was intended to change. 4\/3!! ___ 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
Freddie Chopin wrote: > Just as Peter suspected the problem is caused by commit > a62d8f2271312ba955e839509590f5a5975b1b49. I've verified that with > bisecting. I've also build version with that single commit reverted > which worked as expected and as before. Thanks for confirming that! > I've pushed revert-patch for Gerrit review. Nak. > I believe it should be reverted for now but the general idea it > introduced (easing use of global variables) is worth implementing > but in some other way. Not so easy. I disagree with reverting the patch without having a clear plan for the real fix. Not easy because it is not neccessarily possible to implement the same functionality in any other way. The proper solution requries Jim expertise which I have none, or possibly Tcl expertise which I have very very little. If pressed for a solution, I would look into a workaround for the double evaluation, such as a way to escape any \ in $filename. But I disagree with reverting the commit. Fix the problem instead. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clang static analyzer
Øyvind Harboe wrote: > I upgraded to Ubuntu 11.10 from Ubuntu 11.04 and now it works :-) > > Looks like this is bleeding edge stuff... Not really, it is more likely just not something that Canonical cares so much about. //Peter ___ 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 2011-10-21 19:39, Peter Stuge wrote: Not so easy. I disagree with reverting the patch without having a clear plan for the real fix. Not easy because it is not neccessarily possible to implement the same functionality in any other way. The proper solution requries Jim expertise which I have none, or possibly Tcl expertise which I have very very little. If pressed for a solution, I would look into a workaround for the double evaluation, such as a way to escape any \ in $filename. But I disagree with reverting the commit. Fix the problem instead. What? So you don't know how to fix that, I don't know how to fix that, but we cannot revert a one-line change that introduced A BUG just because it (supposedly - I did not check) adds some functionality that was not actually discussed in detail EVER? Why can't we revert a change, fixing a bug and wait for a real jimtcl-expert (Steve) to discuss other alternatives while in the meantime OpenOCD would work as expected for Windows users? "The problem" is that Windows paths now cannot be used normally and OpenOCD cannot be used as before. Global variables thing which this patch (supposedly) improves is just an improvement, because you could use globals before anyway, just had to add "global NAME" before. Please revert to fix a real problem (removing backslashes from Windows paths). We can deal with improvement while at the same time OpenOCD works as it should. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] commit a62d8f22 causes double evaluation of $filename in src/helper/startup.tcl proc script
Freddie Chopin wrote: >> But I disagree with reverting the commit. Fix the problem instead. > > What? > > So you don't know how to fix that, I don't know how to fix that, but > we cannot revert a one-line change that introduced A BUG just > because it (supposedly - I did not check) adds some functionality > that was not actually discussed in detail EVER? It is obvious that the commit is a significant improvement for life in Tcl files, that needs no discussion. Thus, we really want it. We can also assume that Steve did not pick this way to do the improvement because he likes to bully Windows users, but because it is the better way to reach the goal. We have discovered a side effect of uplevel, so we should find out how we can deal with that side effect, not abandon the improvement. > Why can't we revert a change, fixing a bug and wait for a real > jimtcl-expert (Steve) to discuss other alternatives Maybe you, like me, roughly know the capabilities of Tcl, even if you are not an expert? It is a pretty basic language, so it is fairly safe to assume that there is no alternative to uplevel. > while in the meantime OpenOCD would work as expected for Windows > users? Of course I agree that it would be great to fix the problem quickly. But abandoning the improvement is not the answer. > "The problem" is that Windows paths now cannot be used normally and > OpenOCD cannot be used as before. It is trivial to work around this problem. Open src/startup.tcl and remove uplevel #0 from line 58, and you are done. Since src/startup.tcl is generated during build, git will not care that it has been changed. Of course the workaround needs to be re-applied in case one of the .tcl files that make up startup.tcl changes, by your hand or by a commit you fetch. > Global variables thing which this patch (supposedly) improves is > just an improvement, because you could use globals before anyway, > just had to add "global NAME" before. I think it's a very desirable improvement, and even though it does not directly affect what you and I have so far focused on in OpenOCD (ie. not .tcl files) I guess you agree that it can make a difference for those who do work with .tcl files. More importantly, every user is exposed to the .tcl files, so anything that allows to simplify or clarify them is real important. > Please revert to fix a real problem (removing backslashes from > Windows paths). This is not the problem, this is just how double evaluation manifests itself. Since when is treating the symptom any good? > We can deal with improvement while at the same time OpenOCD works > as it should. Please do deal with the improvement right away. I don't expect it will have to be very complicated. Meanwhile, the workaround is quite trivial. I'm more interested in knowing if not using uplevel also changes which directory relative paths are relative to? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] commit a62d8f22 causes double evaluation of $filename in src/helper/startup.tcl proc script
On 2011-10-21 20:13, Peter Stuge wrote: Meanwhile, the workaround is quite trivial. Yeah, right... Tell that to thousands of OpenOCD users who do NOT build their binary. How can they change startup.tcl when it's hardcoded into openocd.exe? I'm more interested in knowing if not using uplevel also changes which directory relative paths are relative to? It doesn't - it's a side effect of some kind. That's the one and only change that caused problems described before. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] commit a62d8f22 causes double evaluation of $filename in src/helper/startup.tcl proc script
Hi Freddie, as a policy we wait for all information that we expect to arrive on a bug so that we can hopefully fix the problem once and for all. This is slower, but ultimately means higher quality because we make more informed changes to OpenOCD. It isn't going to make a difference if we wait for a week on this one and there is a known workaround. It's speeding things along nicely that you're helping to fill in the information. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Amontec - Out of business?
Hello, Does anybody here know if Amontec - makers of JTAG Tiny - company went out of business or something? I know, this is an off topic question. But I have exhausted all my options before posting it here. Since, Amontec's SDK kit supports OpenOCD, I figured some of you might know their status. Here's the reason I asked. I bought a JTAG tiny from them like 3-4 weeks ago. The payment went through and I haven't heard back from them. I have tried to send multiple emails and I don't get any response back. If they are indeed out of business, I will have to buy another JTAG dongle. But, if they are still in business, I guess I don't have any other option than to warn people to not to deal with them. Well, I will wait for some of you to respond before I do that. Thanks, Ananda ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: 2f7714a buspirate: ignore return value and fix warning
This is an automated email from Gerrit.
?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/43
-- gerrit
commit 2f7714a90cdb829a7a5d4f7596b189728ba0ac8d
Author: Ãyvind Harboe
Date: Sat Oct 22 00:40:51 2011 +0200
buspirate: ignore return value and fix warning
Perhaps we could do one better and propagate the error?
Change-Id: Idc45f516c26f09de4ee01fe05e8d3475f4b80db3
Signed-off-by: Ãyvind Harboe
diff --git a/src/jtag/drivers/buspirate.c b/src/jtag/drivers/buspirate.c
index 62ab008..3a368eb 100644
--- a/src/jtag/drivers/buspirate.c
+++ b/src/jtag/drivers/buspirate.c
@@ -757,13 +757,13 @@ static void buspirate_jtag_enable(int fd)
static void buspirate_jtag_reset(int fd)
{
- int ret;
char tmp[5];
tmp[0] = 0x00; /* exit OCD1 mode */
buspirate_serial_write(fd, tmp, 1);
usleep(1);
- ret = buspirate_serial_read(fd, tmp, 5);
+ /* We ignore the return value here purposly, nothing we can do */
+ buspirate_serial_read(fd, tmp, 5);
if (strncmp(tmp, "BBIO1", 5) == 0) {
tmp[0] = 0x0F; /* reset BP */
buspirate_serial_write(fd, tmp, 1);
--
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: 19fcc78 server: remove warning due to dead assignment
This is an automated email from Gerrit. ?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/44 -- gerrit commit 19fcc78a930eb6e1d1c60cf1df4aa7fc2f1271fb Author: Ãyvind Harboe Date: Sat Oct 22 01:04:27 2011 +0200 server: remove warning due to dead assignment Change-Id: Idb08aef0c11b3fae92286e8fcea61ab09ab09e74 Signed-off-by: Ãyvind Harboe diff --git a/src/server/server.c b/src/server/server.c index 84ec1ac..bb60fc5 100644 --- a/src/server/server.c +++ b/src/server/server.c @@ -71,8 +71,11 @@ static int add_connection(struct service *service, struct command_context *cmd_c c->fd_out = c->fd; /* This increases performance dramatically for e.g. GDB load which -* does not have a sliding window protocol. */ - retval = setsockopt(c->fd, /* socket affected */ +* does not have a sliding window protocol. +* +* Ignore errors from this fn as it probably just means less performance +*/ + setsockopt(c->fd, /* socket affected */ IPPROTO_TCP,/* set option at TCP level */ TCP_NODELAY,/* name of option */ (char *)&flag, /* the cast is historical cruft */ -- ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: d1857ad tms470: remove dead assignment warning
This is an automated email from Gerrit. ?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/45 -- gerrit commit d1857ad1f392b5e700d9d977ab65d827204f6957 Author: Ãyvind Harboe Date: Sat Oct 22 01:06:26 2011 +0200 tms470: remove dead assignment warning Change-Id: I21e7ac47f80d93c9c0d7b169f8848b929c664b20 Signed-off-by: Ãyvind Harboe diff --git a/src/flash/nor/tms470.c b/src/flash/nor/tms470.c index dd9ff5b..f497b38 100644 --- a/src/flash/nor/tms470.c +++ b/src/flash/nor/tms470.c @@ -1248,9 +1248,7 @@ static int get_tms470_info(struct flash_bank *bank, char *buf, int buf_size) buf += used; buf_size -= used; - used += snprintf(buf, buf_size, "Flash protection level 2 is %s\n", tms470_check_flash_unlocked(bank->target) == ERROR_OK ? "disabled" : "enabled"); - buf += used; - buf_size -= used; + snprintf(buf, buf_size, "Flash protection level 2 is %s\n", tms470_check_flash_unlocked(bank->target) == ERROR_OK ? "disabled" : "enabled"); return ERROR_OK; } -- ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: f6522f3 fm3: fix warning for superfluous assignment
This is an automated email from Gerrit. ?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/46 -- gerrit commit f6522f3799e861bb06eec8aae41e27892fbbce13 Author: Ãyvind Harboe Date: Sat Oct 22 01:08:16 2011 +0200 fm3: fix warning for superfluous assignment Change-Id: I4f8e8c2e676a2728ddc6227daf9ca6a7ceb3d505 Signed-off-by: Ãyvind Harboe diff --git a/src/flash/nor/fm3.c b/src/flash/nor/fm3.c index 1e2adf5..e852589 100644 --- a/src/flash/nor/fm3.c +++ b/src/flash/nor/fm3.c @@ -643,7 +643,6 @@ static int fm3_probe(struct flash_bank *bank) bank->sectors = malloc(sizeof(struct flash_sector) * num_pages); bank->base = 0x; - num_pages = 2; /* start with smallest Flash pages number */ bank->size = 32 * 1024; /* bytes */ bank->sectors[0].offset = 0; -- ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: 22d28c0 kinetis: fix warning about malloc(0) w/assert
This is an automated email from Gerrit.
?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/47
-- gerrit
commit 22d28c08fc5f0d8ef9a87dd5c9588a6e027b54b0
Author: Ãyvind Harboe
Date: Sat Oct 22 01:09:32 2011 +0200
kinetis: fix warning about malloc(0) w/assert
Change-Id: Ib40204675bfc5429c744f9ed7e2f7098384b753d
Signed-off-by: Ãyvind Harboe
diff --git a/src/flash/nor/kinetis.c b/src/flash/nor/kinetis.c
index 2613522..ecc60be 100644
--- a/src/flash/nor/kinetis.c
+++ b/src/flash/nor/kinetis.c
@@ -467,6 +467,7 @@ static int kinetis_probe(struct flash_bank *bank)
}
bank->num_sectors = bank->size / (2 * 1024);
+ assert(bank->num_sectors > 0);
bank->sectors = malloc(sizeof(struct flash_sector) * bank->num_sectors);
for (i = 0; i < bank->num_sectors; i++) {
--
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: d42e353 mx2: add error propagation and remove warnings
This is an automated email from Gerrit. ?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/48 -- gerrit commit d42e3535a11b2ce1dc705e9a5a273c9f75f1829a Author: Ãyvind Harboe Date: Sat Oct 22 01:11:58 2011 +0200 mx2: add error propagation and remove warnings Change-Id: Idd4fb452790e5d7921a749679dbd865586e5a4a9 Signed-off-by: Ãyvind Harboe diff --git a/src/flash/nand/mx2.c b/src/flash/nand/mx2.c index 77ae138..6c3c550 100644 --- a/src/flash/nand/mx2.c +++ b/src/flash/nand/mx2.c @@ -501,15 +501,20 @@ static int imx27_read_page(struct nand_device *nand, uint32_t page, return retval; } /* Reset address_cycles before imx27_command ?? */ - retval = ERROR_OK; - retval |= imx27_command(nand, NAND_CMD_READ0); - - retval |= imx27_address(nand, 0); //col - retval |= imx27_address(nand, 0); //col - retval |= imx27_address(nand, page & 0xff); //page address - retval |= imx27_address(nand, (page >> 8) & 0xff); //page address - retval |= imx27_address(nand, (page >> 16) & 0xff); //page address - retval |= imx27_command(nand, NAND_CMD_READSTART); + retval = imx27_command(nand, NAND_CMD_READ0); + if (retval != ERROR_OK) return retval; + retval = imx27_address(nand, 0); //col + if (retval != ERROR_OK) return retval; + retval = imx27_address(nand, 0); //col + if (retval != ERROR_OK) return retval; + retval = imx27_address(nand, page & 0xff); //page address + if (retval != ERROR_OK) return retval; + retval = imx27_address(nand, (page >> 8) & 0xff); //page address + if (retval != ERROR_OK) return retval; + retval = imx27_address(nand, (page >> 16) & 0xff); //page address + if (retval != ERROR_OK) return retval; + retval = imx27_command(nand, NAND_CMD_READSTART); + if (retval != ERROR_OK) return retval; target_write_u16(target, MX2_NF_BUFADDR, 0); mx2_nf_info->fin = MX2_NF_FIN_DATAOUT; -- ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Amontec - Out of business?
Hi Ananda, Ananda Regmi wrote: > Does anybody here know if Amontec - makers of JTAG Tiny - company > went out of business or something? I guess it's possible, but company owner Laurent posted to this very mailing list a week or so ago. > Here's the reason I asked. I bought a JTAG tiny from them like 3-4 weeks > ago. The payment went through and I haven't heard back from them. I have > tried to send multiple emails and I don't get any response back. If they > are indeed out of business, I will have to buy another JTAG dongle. But, > if they are still in business, I guess I don't have any other option > than to warn people to not to deal with them. Thanks for the info. Laurent and a guy that he hired to do some development have participated on this mailing list before, so I think they should also receive this, and will hopefully get back to you soon. Personally I really like the Versaloon dongle, since it is fairly intelligent, and also open hardware, with open source firmware. http://www.versaloon.com/ It works great with OpenOCD for JTAG, SWD I (still :/ ) haven't tested yet. //Peter ___ 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 Sat, Oct 22, 2011 at 1:52 AM, Freddie Chopin wrote: > Why can't we revert a change, fixing a bug and wait for a real jimtcl-expert > (Steve) to discuss other alternatives while in the meantime OpenOCD would > work as expected for Windows users? > > "The problem" is that Windows paths now cannot be used normally and OpenOCD > cannot be used as before. Global variables thing which this patch > (supposedly) improves is just an improvement, because you could use globals > before anyway, just had to add "global NAME" before. > > Please revert to fix a real problem (removing backslashes from Windows > paths). We can deal with improvement while at the same time OpenOCD works as > it should. I have to agree with you here. Make things work first, nice to have but not essential things can come later. -- Xiaofan ___ 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
> I have to agree with you here. Make things work first, nice to have but > not essential things can come later. It's a policy to reduce the # of unnecessary changes to OpenOCD. The # of willy-nilly changes in itself drives the quality down. We don't understand this problem yet, so we're likely to knock something else over by being impatient here. If it takes a week or two before all the information arrives, then it's a bargain for the improved quality to OpenOCD that we receive from this policy. We just implemented an automated system to track the progress and development of such patches. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: 0b0da27 warning: fix false positive
This is an automated email from Gerrit. ?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/49 -- gerrit commit 0b0da279276e47b49f002374735e0570544cf32b Author: Øyvind Harboe Date: Sat Oct 22 08:25:00 2011 +0200 warning: fix false positive may be used uninitialized in this function [-Werror=uninitialized] Change-Id: Ida2cf8efe4e7da6fd9f669b806a20894563ac3d4 Signed-off-by: Øyvind Harboe diff --git a/src/jtag/core.c b/src/jtag/core.c index b26701e..ad63753 100644 --- a/src/jtag/core.c +++ b/src/jtag/core.c @@ -1398,7 +1398,7 @@ int adapter_init(struct command_context *cmd_ctx) int requested_khz = jtag_get_speed_khz(); int actual_khz = requested_khz; - int jtag_speed_var; + int jtag_speed_var = 0; retval = jtag_get_speed(&jtag_speed_var); if (retval != ERROR_OK) return retval; -- ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Jenkins changes
I'd like to drive the OpenOCD code towards zero scan-build (clang static analysis) warnings and I'd very much appreciate patches to that effect! I've added a scan-build (clang static analysis) that is run when a patch is submitted (openocd-gerrit). If scan-build fails, then the patch is still marked as verified. For now. You can look at the build output to find the warnings that scan-build shows, so you don't need clang installed on your machine to fix these warnings, just look at the jenkins build output. When a patch is submitted to the main repository, scan-build warnings *will* cause a failure. Hopefully this will drive us towards zero scan-build warnings. Also, -O3 is added, which can yield an occasional extra warning compared to -O2(default). -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
