Re: [Openocd-development] Config file format/line endings
On 16/11/2010, at 11:36 AM, Andrew Leech wrote: > On Tue, Nov 16, 2010 at 12:19 PM, Steve Bennett > wrote: >> >> On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote: >> >>> On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett >>> wrote: On 16/11/2010, at 9:27 AM, Andrew Leech wrote: > Hi all, > I've just found a compiling/usage difficulty with the git version on > cygwin. Apparently somewhere between 0.4.0 and mainline (possibly > jimtcl?) openocd no longer handles dos line endings on config files. > Apparently all my config files of my existing 0.4.0 installation have > dos line endings and I'd never realised or cared, but I compiled git > on cygwin and tried to use it with my existing openocd.cfg and was > treated to this error: > > Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00) > Licensed under GNU GPL v2 > For bug reports, read >http://openocd.berlios.de/doc/doxygen/bugs.html > Runtime Error: embedded:startup.tcl:57: > in procedure 'script' > at file "embedded:startup.tcl", line 57 > > This is a very un-user-friendly error message and had me stumped, I > though my build was broken or something. It took me a lot of stuffing > around with config files to realise it was just a dos2unix on my > config file away from working, and now I'm all good. > I personally don't have an issue with requiring unix line endings, > it's just that this is a nasty way to fail, a cleaner error message > would have been useful. I suspect the problem is here in src/helper/startup.tcl set errmsg [format "%s: command requires more arguments" \ [concat $name " " $args]] The backslash newline sequence will likely have a carriage return inserted. The easy solution is to ensure that these startup files are read in text mode or have the \r\n translated to \n before creating startup_tcl.c But it would also be nice if each startup script were evaluated independently with the original filename, and any error message shown. >>> >>> A large startup.tcl is generated by the makefiles from many smaller >>> startup.tcl scripts around the source tree. This startup.tcl is then >>> converted >>> to .c and linked into openocd. Why? Because it was felt that it was an >>> important >>> feature to be able to launch openocd without a dependency on the files that >>> openocd ships with. >> >> Nothing wrong with that. Jim Tcl does something similar to allow Tcl >> extensions >> to be linked in. For example, stdlib.tcl, tclcompat.tcl and glob.tcl >> >> The trick is to invoke Jim_Eval_Named() once for each file so that the >> original >> source file can be identified, and also to display any error which is >> generated. >> > > I don't know that the line ending problem is with (the compiled in) > startup.tcl. I only did the dos2unix on my openocd.cfg and associated > cfg text files, and then they worked fine with the same openocd > binary. > > Is openocd supposed to still work with dos format .cfg files? Interesting. There hasn't been any change in Jim Tcl in this respect. I'm surprised it ever worked. Isn't there a global setting in cygwin for whether files are opened in binary mode or text mode by default? > > Andrew > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file format/line endings
On Tue, Nov 16, 2010 at 12:19 PM, Steve Bennett wrote: > > On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote: > >> On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett >> wrote: >>> On 16/11/2010, at 9:27 AM, Andrew Leech wrote: >>> Hi all, I've just found a compiling/usage difficulty with the git version on cygwin. Apparently somewhere between 0.4.0 and mainline (possibly jimtcl?) openocd no longer handles dos line endings on config files. Apparently all my config files of my existing 0.4.0 installation have dos line endings and I'd never realised or cared, but I compiled git on cygwin and tried to use it with my existing openocd.cfg and was treated to this error: Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Runtime Error: embedded:startup.tcl:57: in procedure 'script' at file "embedded:startup.tcl", line 57 This is a very un-user-friendly error message and had me stumped, I though my build was broken or something. It took me a lot of stuffing around with config files to realise it was just a dos2unix on my config file away from working, and now I'm all good. I personally don't have an issue with requiring unix line endings, it's just that this is a nasty way to fail, a cleaner error message would have been useful. >>> >>> I suspect the problem is here in src/helper/startup.tcl >>> >>> set errmsg [format "%s: command requires more arguments" \ >>> [concat $name " " $args]] >>> >>> The backslash newline sequence will likely have a carriage return inserted. >>> The easy solution is to ensure that these startup files are read in text >>> mode >>> or have the \r\n translated to \n before creating startup_tcl.c >>> >>> But it would also be nice if each startup script were evaluated >>> independently >>> with the original filename, and any error message shown. >> >> A large startup.tcl is generated by the makefiles from many smaller >> startup.tcl scripts around the source tree. This startup.tcl is then >> converted >> to .c and linked into openocd. Why? Because it was felt that it was an >> important >> feature to be able to launch openocd without a dependency on the files that >> openocd ships with. > > Nothing wrong with that. Jim Tcl does something similar to allow Tcl > extensions > to be linked in. For example, stdlib.tcl, tclcompat.tcl and glob.tcl > > The trick is to invoke Jim_Eval_Named() once for each file so that the > original > source file can be identified, and also to display any error which is > generated. > I don't know that the line ending problem is with (the compiled in) startup.tcl. I only did the dos2unix on my openocd.cfg and associated cfg text files, and then they worked fine with the same openocd binary. Is openocd supposed to still work with dos format .cfg files? Andrew ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file format/line endings
On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote: > On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett wrote: >> On 16/11/2010, at 9:27 AM, Andrew Leech wrote: >> >>> Hi all, >>> I've just found a compiling/usage difficulty with the git version on >>> cygwin. Apparently somewhere between 0.4.0 and mainline (possibly >>> jimtcl?) openocd no longer handles dos line endings on config files. >>> Apparently all my config files of my existing 0.4.0 installation have >>> dos line endings and I'd never realised or cared, but I compiled git >>> on cygwin and tried to use it with my existing openocd.cfg and was >>> treated to this error: >>> >>> Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00) >>> Licensed under GNU GPL v2 >>> For bug reports, read >>>http://openocd.berlios.de/doc/doxygen/bugs.html >>> Runtime Error: embedded:startup.tcl:57: >>> in procedure 'script' >>> at file "embedded:startup.tcl", line 57 >>> >>> This is a very un-user-friendly error message and had me stumped, I >>> though my build was broken or something. It took me a lot of stuffing >>> around with config files to realise it was just a dos2unix on my >>> config file away from working, and now I'm all good. >>> I personally don't have an issue with requiring unix line endings, >>> it's just that this is a nasty way to fail, a cleaner error message >>> would have been useful. >> >> I suspect the problem is here in src/helper/startup.tcl >> >>set errmsg [format "%s: command requires more arguments" \ >>[concat $name " " $args]] >> >> The backslash newline sequence will likely have a carriage return inserted. >> The easy solution is to ensure that these startup files are read in text mode >> or have the \r\n translated to \n before creating startup_tcl.c >> >> But it would also be nice if each startup script were evaluated independently >> with the original filename, and any error message shown. > > A large startup.tcl is generated by the makefiles from many smaller > startup.tcl scripts around the source tree. This startup.tcl is then converted > to .c and linked into openocd. Why? Because it was felt that it was an > important > feature to be able to launch openocd without a dependency on the files that > openocd ships with. Nothing wrong with that. Jim Tcl does something similar to allow Tcl extensions to be linked in. For example, stdlib.tcl, tclcompat.tcl and glob.tcl The trick is to invoke Jim_Eval_Named() once for each file so that the original source file can be identified, and also to display any error which is generated. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file format/line endings
On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett wrote: > On 16/11/2010, at 9:27 AM, Andrew Leech wrote: > >> Hi all, >> I've just found a compiling/usage difficulty with the git version on >> cygwin. Apparently somewhere between 0.4.0 and mainline (possibly >> jimtcl?) openocd no longer handles dos line endings on config files. >> Apparently all my config files of my existing 0.4.0 installation have >> dos line endings and I'd never realised or cared, but I compiled git >> on cygwin and tried to use it with my existing openocd.cfg and was >> treated to this error: >> >> Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00) >> Licensed under GNU GPL v2 >> For bug reports, read >> http://openocd.berlios.de/doc/doxygen/bugs.html >> Runtime Error: embedded:startup.tcl:57: >> in procedure 'script' >> at file "embedded:startup.tcl", line 57 >> >> This is a very un-user-friendly error message and had me stumped, I >> though my build was broken or something. It took me a lot of stuffing >> around with config files to realise it was just a dos2unix on my >> config file away from working, and now I'm all good. >> I personally don't have an issue with requiring unix line endings, >> it's just that this is a nasty way to fail, a cleaner error message >> would have been useful. > > I suspect the problem is here in src/helper/startup.tcl > > set errmsg [format "%s: command requires more arguments" \ > [concat $name " " $args]] > > The backslash newline sequence will likely have a carriage return inserted. > The easy solution is to ensure that these startup files are read in text mode > or have the \r\n translated to \n before creating startup_tcl.c > > But it would also be nice if each startup script were evaluated independently > with the original filename, and any error message shown. A large startup.tcl is generated by the makefiles from many smaller startup.tcl scripts around the source tree. This startup.tcl is then converted to .c and linked into openocd. Why? Because it was felt that it was an important feature to be able to launch openocd without a dependency on the files that openocd ships with. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file format/line endings
On 16/11/2010, at 9:27 AM, Andrew Leech wrote: > Hi all, > I've just found a compiling/usage difficulty with the git version on > cygwin. Apparently somewhere between 0.4.0 and mainline (possibly > jimtcl?) openocd no longer handles dos line endings on config files. > Apparently all my config files of my existing 0.4.0 installation have > dos line endings and I'd never realised or cared, but I compiled git > on cygwin and tried to use it with my existing openocd.cfg and was > treated to this error: > > Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00) > Licensed under GNU GPL v2 > For bug reports, read >http://openocd.berlios.de/doc/doxygen/bugs.html > Runtime Error: embedded:startup.tcl:57: > in procedure 'script' > at file "embedded:startup.tcl", line 57 > > This is a very un-user-friendly error message and had me stumped, I > though my build was broken or something. It took me a lot of stuffing > around with config files to realise it was just a dos2unix on my > config file away from working, and now I'm all good. > I personally don't have an issue with requiring unix line endings, > it's just that this is a nasty way to fail, a cleaner error message > would have been useful. I suspect the problem is here in src/helper/startup.tcl set errmsg [format "%s: command requires more arguments" \ [concat $name " " $args]] The backslash newline sequence will likely have a carriage return inserted. The easy solution is to ensure that these startup files are read in text mode or have the \r\n translated to \n before creating startup_tcl.c But it would also be nice if each startup script were evaluated independently with the original filename, and any error message shown. > > Cheers, > Andrew > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)
On Mon, Nov 15, 2010 at 1:05 PM, Andrew Leech wrote: > On Sat, Nov 13, 2010 at 1:28 AM, Peter Stuge wrote: > >>> There's specific HDR and similar commands in svf to define these >>> paddings. >> >>> Some software like UrJtag ignores these commands if they even exist >>> and figures them out itself by scanning the chain, this is neat. >> >> I think this is the only sensible behavior. >> >> >>> The svf player in openocd doesn't have anything like this (and I don't >>> have time right now how to figure out how to add it, maybe later), so >>> you're left with generating the svf files to be aware of the chain, if >>> the software making the svf has this functionality. >> >> Or maybe OpenOCD can patch in the neccessary stuff into the SVF? >> > > Yeah I would like to add automatic support for this in openocd, it > really would be quite trivial. Basically add an optional switch to the > svf command to target a specific tap which would then ignore any > header/trailer commands in the svf and run the appropriate command > before running the supplied svf. > For reference here's a svf header for my chain (trimmed and commented by me) > >>!# Chain header for configuration of: >>!# tap 1: jtag newtap lpc3131 cpu -irlen 4 -expected-id 0x07926f0f >>!# tap 2: jtag newtap a3p125 tap -irlen 8 -expected-id 0x02a121cf >>!# >>STATE RESET; >>RUNTEST IDLE 5 TCK 200E-6 SEC; >>ENDIR IDLE; >>SIR 12 TDI(00f) TDO(000) MASK(000); !# put lpc IR = 0xF (bypass mode), and a3p IR = 0x00 (do nothing?) >>ENDIR IRPAUSE; >>HDR 1 TDI(0); !# Set 1 bit of data header padding (lpc bypass register at start of chain) >>HIR 4 TDI(f); !# Set 4 bits of instruction header padding (lpc 4 bits of IR at start of chain) >>TDR 0; !# no trailer padding (no taps on chain after a3p) >>TIR 0; >>!# >>!# Continue with rest of original SVF >>FREQUENCY 4E6 HZ; >>STATE RESET; >>RUNTEST IDLE 5 TCK; >>ENDIR IRPAUSE; >>ENDDR DRPAUSE; >>SDR 32 TDI() TDO(03A121CF) MASK(06FF); >>!# > > The original header from actel had a few extra tests than is here, I > trimmed it to basically the minimum that works, and these commands > would be very easy to auto generate. Not sure if/when I might find > time to add this to openocd though. Pretty easy to add these commands > to a SVF manually in the mean time. This header is certainly worth > having on the wiki page about SVF I feel. > Ok so I decided I could add support for this to openocd. The trimmed header above is still bigger than required, the line where it puts lpc into bypass mode isn't required either, this was just part of the test on whether the chain is set up correctly. I feel I can rely on openocd to ensure the chain is right, so didn't include it in the patch. All I need to do is set the HDR/HIR/TDR/TIR commands. The route I took in this patch is to add a new command line switch to the svf command which mirrors the usage that the xsvf module already has: "usage: svf [quiet]" So if you want to run the svf unmodified specify plain before the filename, in which case the svf is run exactly the same way as the svf module currently runs. To target a specific device give its dotted name before the filename. When a dotted name is given the code calculated appropriate values for the HDR/HIR/TDR/TIR commands and manually runs these through the existing command parser. It then disables these commands in the parser to ensure the values are not overwritten by any existing commands in the svf file. Seeing as these commands already work to set up the padding I thought it easiest to use the existing system rather than finding and directly setting the lower level settings. This patch has changed the command syntax from the existing module, so it's not directly compatible with any users existing scripts if people are using the svf command. I could put the dotted name as an optional command at the end (after quiet) if compatibility was preferred, however I thought it best to make it consistent with the xsvf module command. Any input on this decision is welcomed. This patch hasn't yet been tested on any system other than my one custom hardware, although it's fairly straightforward so I don't see there being too many issues. Andrew svf_chain.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Config file format/line endings
Hi all, I've just found a compiling/usage difficulty with the git version on cygwin. Apparently somewhere between 0.4.0 and mainline (possibly jimtcl?) openocd no longer handles dos line endings on config files. Apparently all my config files of my existing 0.4.0 installation have dos line endings and I'd never realised or cared, but I compiled git on cygwin and tried to use it with my existing openocd.cfg and was treated to this error: Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Runtime Error: embedded:startup.tcl:57: in procedure 'script' at file "embedded:startup.tcl", line 57 This is a very un-user-friendly error message and had me stumped, I though my build was broken or something. It took me a lot of stuffing around with config files to realise it was just a dos2unix on my config file away from working, and now I'm all good. I personally don't have an issue with requiring unix line endings, it's just that this is a nasty way to fail, a cleaner error message would have been useful. Cheers, Andrew ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Build inline jimtcl
On 16/11/2010, at 6:05 AM, Spencer Oliver wrote: >> >> This looks like it is heading in the right direction. >> >>> >>> As mentioned above we are currently adding a hack so jimtcl builds inline - >>> this is fine for the standard configure/make case. >> >> Can you explain why you needed -DHAVE_NO_AUTOCONF? >> I tried with the latest version of jimtcl and it didn't need this. >> > > This is only required when using jim inline. > If using an external lib then all is ok, it is due to multiple defines: > It seesm due to the inclustion of jimautoconf.h from jim.h:94 > > In file included from ../../../openocd/jimtcl/jim.h:94, > [snip] > I have not tried jim git head - onlt the version that is linked to openocd > 0.63 As I suspected. This is fixed in: http://repo.or.cz/w/jimtcl.git/commit/5a9c9cdc1a0add1d0e6e63e64d5d7d7febc6d749 Please try at least this version and you can get rid of -DHAVE_NO_AUTOCONF which could lead to problems with 32 vs 64 bit integers on some platforms. > >>> >>> Running a few other tests shows that to use jimtcl inline the jimtcl build >>> system will need other updates to function as per openocd. >>> For example make dist/distcheck will fail as jimtcl does not support the >>> std autotools options. >> >> Tell me what you need these targets to do. >> > > i have noticed that jim only really uses autoconf, but does not use automake. > OpenOCD uses both and so expects the standard make targets, eg: > http://www.gnu.org/software/automake/manual/html_node/Third_002dParty-Makefiles.html#Third_002dParty-Makefiles > > we can work around this many ways depending on how much/little work you fancy > doing :) I won't use automake, but I can probably add all of these targets to be compatible. Most of them are likely to be nops. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Build inline jimtcl
This looks like it is heading in the right direction. As mentioned above we are currently adding a hack so jimtcl builds inline - this is fine for the standard configure/make case. Can you explain why you needed -DHAVE_NO_AUTOCONF? I tried with the latest version of jimtcl and it didn't need this. This is only required when using jim inline. If using an external lib then all is ok, it is due to multiple defines: It seesm due to the inclustion of jimautoconf.h from jim.h:94 In file included from ../../../openocd/jimtcl/jim.h:94, from ../../../openocd/src/helper/command.h:34, from ../../../openocd/src/helper/log.h:29, from ../../../openocd/src/target/breakpoints.c:25: ../../jimtcl/jimautoconf.h:113:1: warning: "PACKAGE_BUGREPORT" redefined In file included from ../../../openocd/src/target/breakpoints.c:21: ../../config.h:228:1: warning: this is the location of the previous definition In file included from ../../../openocd/jimtcl/jim.h:94, from ../../../openocd/src/helper/command.h:34, from ../../../openocd/src/helper/log.h:29, from ../../../openocd/src/target/breakpoints.c:25: ../../jimtcl/jimautoconf.h:116:1: warning: "PACKAGE_NAME" redefined In file included from ../../../openocd/src/target/breakpoints.c:21: ../../config.h:231:1: warning: this is the location of the previous definition In file included from ../../../openocd/jimtcl/jim.h:94, from ../../../openocd/src/helper/command.h:34, from ../../../openocd/src/helper/log.h:29, from ../../../openocd/src/target/breakpoints.c:25: ../../jimtcl/jimautoconf.h:119:1: warning: "PACKAGE_STRING" redefined In file included from ../../../openocd/src/target/breakpoints.c:21: ../../config.h:234:1: warning: this is the location of the previous definition In file included from ../../../openocd/jimtcl/jim.h:94, from ../../../openocd/src/helper/command.h:34, from ../../../openocd/src/helper/log.h:29, from ../../../openocd/src/target/breakpoints.c:25: ../../jimtcl/jimautoconf.h:122:1: warning: "PACKAGE_TARNAME" redefined In file included from ../../../openocd/src/target/breakpoints.c:21: ../../config.h:237:1: warning: this is the location of the previous definition In file included from ../../../openocd/jimtcl/jim.h:94, from ../../../openocd/src/helper/command.h:34, from ../../../openocd/src/helper/log.h:29, from ../../../openocd/src/target/breakpoints.c:25: ../../jimtcl/jimautoconf.h:128:1: warning: "PACKAGE_VERSION" redefined In file included from ../../../openocd/src/target/breakpoints.c:21: ../../config.h:243:1: warning: this is the location of the previous definition I have not tried jim git head - onlt the version that is linked to openocd 0.63 Running a few other tests shows that to use jimtcl inline the jimtcl build system will need other updates to function as per openocd. For example make dist/distcheck will fail as jimtcl does not support the std autotools options. Tell me what you need these targets to do. i have noticed that jim only really uses autoconf, but does not use automake. OpenOCD uses both and so expects the standard make targets, eg: http://www.gnu.org/software/automake/manual/html_node/Third_002dParty-Makefiles.html#Third_002dParty-Makefiles we can work around this many ways depending on how much/little work you fancy doing :) Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] flash: fix bug with multiple back-to-back flash chips
On Mon, Nov 15, 2010 at 4:35 PM, Peter Stuge wrote:
> Øyvind Harboe wrote:
>> Note that if an image is too big(even if you have multiple
>> back to back chips), you'll now get an error message that
>> no flash chip is found:
>>
>> LOG_ERROR("No flash at address 0x%08" PRIx32 "\n", addr);
>
> I think this message is misleading. Can this condition be detected
> somehow and a more specific error message be output?
Not without significantly complicating the code, where
the currently broken code is an argument against
such cleverness.
As with exceptions it is relatively straightforward to
propagate the failure to the user. Transforming that
into helpful advice is a MUCH harder problem.
The error message could be worse though...
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] flash: fix bug with multiple back-to-back flash chips
Øyvind Harboe wrote:
> Note that if an image is too big(even if you have multiple
> back to back chips), you'll now get an error message that
> no flash chip is found:
>
> LOG_ERROR("No flash at address 0x%08" PRIx32 "\n", addr);
I think this message is misleading. Can this condition be detected
somehow and a more specific error message be output?
//Peter
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Patch] SPEAr serial NOR flash driver
On Mon, Nov 15, 2010 at 4:07 PM, Peter Stuge wrote: > Øyvind Harboe wrote: >> > there are parts of the patch which should be separated out, >> > because they are not really specific to spearsmi. > .. >> > Refactor now, or then? > .. >> I haven't seen a proposed design and it seems some time off. > > Fair enough. Could we add some commentary to remind future code > pilots of these circumstances? That does seem in order. Would you care to formulate something? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Patch] SPEAr serial NOR flash driver
Øyvind Harboe wrote: > > there are parts of the patch which should be separated out, > > because they are not really specific to spearsmi. .. > > Refactor now, or then? .. > I haven't seen a proposed design and it seems some time off. Fair enough. Could we add some commentary to remind future code pilots of these circumstances? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] flash: fix bug with multiple back-to-back flash chips
flash programming via flash write_image or gdb load would
produce a bogus error message that the flash chip was to
small.
The solution is to limit the current flash programming
run to the current chip.
Signed-off-by: Øyvind Harboe
---
src/flash/nor/core.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/flash/nor/core.c b/src/flash/nor/core.c
index 2c1d9de..da73bf6 100644
--- a/src/flash/nor/core.c
+++ b/src/flash/nor/core.c
@@ -654,9 +654,13 @@ int flash_write_unlock(struct target *target, struct image
*image,
if (run_address + run_size - 1 > c->base + c->size - 1)
{
- LOG_ERROR("The image is too big for the flash");
- retval = ERROR_FAIL;
- goto done;
+ /* If we have more than one flash chip back to back,
then we limit
+* the current write operation to the current chip.
+*/
+ LOG_DEBUG("Truncate flash run size to the current flash
chip.");
+
+ run_size = c->base + c->size - run_address;
+ assert(run_size > 0);
}
/* If we're applying any sector automagic, then pad this
--
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] flash: fix bug with multiple back-to-back flash chips
Note that if an image is too big(even if you have multiple
back to back chips), you'll now get an error message that
no flash chip is found:
LOG_ERROR("No flash at address 0x%08" PRIx32 "\n", addr);
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Patch] SPEAr serial NOR flash driver
On Sat, Nov 13, 2010 at 1:09 PM, Peter Stuge wrote: > Øyvind Harboe wrote: >> So basically if OpenOCD had some generic support for >> interfacing to SPI chips via the target CPU over JTAG, >> then you could build on that for your flash driver? >> >> That seems a completely separate feature to your patch. > > That's the point basically, there are parts of the patch which should > be separated out, because they are not really specific to spearsmi. > > >> Your flash driver could be refactored once such support >> was added, possibly by factoring out some code from >> your flash driver. > > Refactor now, or then? Copypaste later is more likely what we'll > see.. I haven't seen a proposed design and it seems some time off. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Retire httpd
On Sat, Nov 13, 2010 at 10:17 AM, Øyvind Harboe wrote: > Going twice... Merged. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Add comments and tiny improvements to STM32 flash loader algorithm
Merged. Thanks! On Sat, Nov 13, 2010 at 3:59 PM, Freddie Chopin wrote: > Hi all! > > Very small improvement. Tested on STM32, worst-case speed improvement is > ~1.5%, best-case - ~3%. > > Old one: >> stm32x mass_erase 0 > stm32x mass erase complete >> flash write_image c:\\stm32.hex > wrote 129296 bytes from file c:\stm32.hex in 10.390625s (12.152 KiB/s) >> stm32x mass_erase 0 > stm32x mass erase complete >> flash write_image c:\\stm32.hex > wrote 129296 bytes from file c:\stm32.hex in 10.390625s (12.152 KiB/s) >> stm32x mass_erase 0 > stm32x mass erase complete >> flash write_image c:\\stm32.hex > wrote 129296 bytes from file c:\stm32.hex in 10.390625s (12.152 KiB/s) > > New one: >> flash write_image c:\\stm32.hex > wrote 129296 bytes from file c:\stm32.hex in 10.109375s (12.490 KiB/s) >> stm32x mass_erase 0 > stm32x mass erase complete >> flash write_image c:\\stm32.hex > wrote 129296 bytes from file c:\stm32.hex in 10.187500s (12.394 KiB/s) >> stm32x mass_erase 0 > stm32x mass erase complete >> flash write_image c:\\stm32.hex > wrote 129296 bytes from file c:\stm32.hex in 10.25s (12.319 KiB/s) >> stm32x mass_erase 0 > stm32x mass erase complete >> flash write_image c:\\stm32.hex > wrote 129296 bytes from file c:\stm32.hex in 10.156250s (12.432 KiB/s) > > Image can be verified and it's fine. > > 4\/3!! > > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > > -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] segfault when gdb connects, but target is not connected
On Mon, Nov 15, 2010 at 8:37 AM, Domen Puncer wrote: > On Sat, Nov 13, 2010 at 13:08, Øyvind Harboe wrote: >> Does the attached patch fix the problem? > > Jup, did the trick. Merged. Thanks for testing & excellent reporting! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
