Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 2010-11-11 19:34, Peter Stuge wrote: / Freddie Chopin wrote: // If no SRST pin is available, Cortex-M3 soft-reset is required, // // How common is this case? // // How common is what? Lack of SRST? // // Yes? / For me such situations are almost impossible, but some strange and bizarre policy makes default target file for stm32 tell OpenOCD there is no reset at all... Of course user can change that, but with this assumption, target, board and interface cfg files can as well be deleted, as the user can write his/her own... Number of things that users of OpenOCD have to do prior to using it for it's main purpose tends to grow, rather than shrink... Yes, you're right ... I (and many other people) like to use OpenOCD with just command-line parameters, like this: openocd -f interface/... -f target/... It worked fine, and that was very cool, because one does not need to prepare millions of config files for each project / occasion. Yes VERY cool, and a part of the success of OpenOCD ! Now with this method peripherals are NOT reset during reset ... command on stm32... I know what to do to fix this, but I bet 95% of OpenOCD users don't. You can decide that it's their problem if you want. The files in target directory are soon going to be useless alone. Completely off-topic: sometimes I think, that open-source projects are just a cover-up made by people working for big companies - they ensure that the software works, but is impossible to use without reading the manual twice, browsing through the mail archives, searching the web for half a day and then reading the manual again... Then they find out that this problem they have is a policy and that it will never be changed, because someone decided that it's the right way to go. OpenOCD project was not started in this way. But it is close to become as you say. Why the OpenOCD was a success, - 1. open-source - 2. easy to use to do BASIC debug - 3. cheap hardware debug (USB JTAG) - 4. easy to come in the project and add new features / patches ... An important point is the BASIC debug - if you want to do more complexe debug you should buy something else DSRTEAM / KEIL / GREENHILLS ... But the complex debug are only for the 1% of users, the 99% will use openocd or something like the excellent Rowley Crossworks ;-) Now, OpenOCD is becoming more more difficult to build (with the dependency of external tools like JimTCL / for me it is not a good thing to have JimTcl as an external module - we will see more troubles in futures.) ... and more and more difficult to use with changing System Reset idea If we do not keep the openocd Easy to use, we will certainly kill it, or we will just provide an Excellent Debug platform for some big company with more manpower, and some company not respecting open-source license ! my 2c. / If SRST is available, no soft-reset is required. // // Of course. What decides on the code path? / I don't understand the question, so here is a blind answer... 1. no chip resets, no cortex-m3 reset method specified - use SYSRESETREQ (now use VECTRESET - does not reset peripherals) 2. chip reset available, cortex-m3 reset method specified - use cortex-m3 reset method that was specified 3. chip resets available, no cortex-m3 reset method specified - use SRST 4. no chip resets, cortex-m3 reset method specified - use it, but if cortex-m3 reset method is SRST that will be changed to SYSRESETREQ (now it will be changed to VECTRESET, note as in 1.) 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 11/11/2010 23:26, Peter Stuge wrote: Freddie Chopin wrote: according to OpenOCD (brilliant) policy of target config files I think it would be great if you stopped complaining using sarcasm and instead help analyze and improve. I think you have a lot of experience that is valuable. The policy stuff is nonsense. If there is a compelling argument then anything and everything will change. In particular if you do it yourself. :) But to make sure that time isn't spent in vain it's very wise to do as you have already done; discuss first. The cortex-m3 reset_config command gets priority (that's my understanding...), I also don't know for sure how this works, but I would assume that a later config file can override an earlier one? and if soft-reset method is selected, real reset will never be used, no matter that it's the best solution. That's obviously useless. Needs to be fixed then. If the board has a reset_config of for example srst_only then that will be used whatever the setting of cortex_m3 reset_config. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How 2 build with new Jim???
On 12/11/2010, at 8:34 AM, Peter Stuge wrote: Øyvind Harboe wrote: By default OpenOCD should build the Jim Tcl submodule automatically, but there should be an option to use the installed Jim Tcl. I disagree strongly with this. Moving Jim out into a separate package means that it should also be treated as a separate package. (Which it is, so it makes perfect sense!) [snip lots of detail about building] I think all this misses the point that *right now* people are trying to build openocd from git and failing. This means there is a problem which needs to be fixed. I don't think telling people to go create (.e.g.) cygwin projects to solve their problem is going to be popular. -- µ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] STM32 reset_config
On 12/11/2010 10:33, Spencer Oliver wrote: On 11/11/2010 23:26, Peter Stuge wrote: Freddie Chopin wrote: according to OpenOCD (brilliant) policy of target config files I think it would be great if you stopped complaining using sarcasm and instead help analyze and improve. I think you have a lot of experience that is valuable. The policy stuff is nonsense. If there is a compelling argument then anything and everything will change. In particular if you do it yourself. :) But to make sure that time isn't spent in vain it's very wise to do as you have already done; discuss first. The cortex-m3 reset_config command gets priority (that's my understanding...), I also don't know for sure how this works, but I would assume that a later config file can override an earlier one? and if soft-reset method is selected, real reset will never be used, no matter that it's the best solution. That's obviously useless. Needs to be fixed then. If the board has a reset_config of for example srst_only then that will be used whatever the setting of cortex_m3 reset_config. Mmm - Think i may be incorrect here, the cortex_m3 reset_config does override the standard reset_config. Looking back this was done so it did not break any stellaris scripts that define reset config. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 11/11/2010 22:26, Freddie Chopin wrote: On 2010-11-11 20:47, Spencer Oliver wrote: I disagree with this patch as SYSTEMRESET is not supported as expected on all cores. Shouldn't the code assume that this standard mechanism works as the standard says? If some chip does not support it, than this chip should have VECTRESET selected in its config file, why make trouble for chips that obey this standard? The standard as you call it says the behaviour is implementation defined for both. It even goes on to state the following: Debuggers must only use VECTRESET when the core is halted, otherwise the effect is UNPREDICTABLE. I also want to get an simple easy reset system working. Then as i mentioned before we need the be aware of what cores support the various reset modes and enable that in the various configs. The default option should be the safe option an *all* cores. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 2010-11-12 12:16, Spencer Oliver wrote: Mmm - Think i may be incorrect here, the cortex_m3 reset_config does override the standard reset_config. Looking back this was done so it did not break any stellaris scripts that define reset config. Would that be enough to change behavior so that hardware reset would be used if available, no matter what option of cortex-m3 reset_config was selected? Option to select srst may be then removed, and this command could be renamed to soft_reset_config. Another solution is to change cortex-m3 reset_config to capabilities model - you list all supported reset options, OpenOCD selects what's best. For example cortex-m3 reset_config srst sysresetreq vectreset would define a chip that can use any method - if srst is available, use that, else use sysresetreq. cortex-m3 reset_config srst vectreset would define a chip that does not handle sysresetreq, so in case of lack of srst, use vectreset. As it's hard to imagine a chip that has no srst, that option can be removed too, and command renamed some way. What do you think? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 2010-11-12 09:21, Laurent Gauch wrote: I (and many other people) like to use OpenOCD with just command-line parameters, like this: openocd -f interface/... -f target/... It worked fine, and that was very cool, because one does not need to prepare millions of config files for each project / occasion. Yes VERY cool, and a part of the success of OpenOCD ! So we have to keep it that way! Having cfg files for ALL supported targets in one solution, and I'm willing to maintain such list for microcontrollers (arm7 and cortex-m3)... Having REAL generic family config files is another solution, but that's not as user friendly as the first solution... Now, OpenOCD is becoming more more difficult to build (with the dependency of external tools like JimTCL / for me it is not a good thing to have JimTcl as an external module - we will see more troubles in futures.) ... and more and more difficult to use with changing System Reset idea If we do not keep the openocd Easy to use, we will certainly kill it, or we will just provide an Excellent Debug platform for some big company with more manpower, and some company not respecting open-source license ! my 2c. You read my mind (; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How 2 build with new Jim???
On 2010-11-12 11:36, Steve Bennett wrote: [snip lots of detail about building] I think all this misses the point that *right now* people are trying to build openocd from git and failing. This means there is a problem which needs to be fixed. I don't think telling people to go create (.e.g.) cygwin projects to solve their problem is going to be popular. I'm no expert in these areas, but for me implementing a mechanism that is used by gcc would be the best solution, and I think that many will agree, as such ideas were spoken already. This mechanism allows to use 3 options: 1. No parameter specified, no jumtcl directory in OpenOCD source tree = use jimtcl library that is installed in the system 2. No parameter specified, jimtcl directory present in OpenOCD source tree = build jimtcl before OpenOCD, use the library in OpenOCD 3. Path to jimtcl library specified = use it in OpenOCD. That's the way gcc handles dependancies like MPFR, GMP, PPL, etc. (or at least I think it does it this way [; ) 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
--- On Fri, 11/12/10, Freddie Chopin freddie_cho...@op.pl wrote: it's hard to imagine a chip that has no srst, As for boards or JTAG adapters without nSRST, no imagination is required; I have production boards of both flavors. that option can be removed Shouldn't be, though; that'd be very unwise. - Dave ___ 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
Any objections out there? Looks OK to me on the surface of it. You're the expert here. I'll let it cool off and if no feedback, I'll merge it. The driver structure follows the prototype of the other drivers in src/flash/nor/ The file .h that I'm adding is totally useless, since only provides a function prototype but is not included by the only user of that function. I'm thinking that it would make more sense to get rid of all the .h files where a simple fn prototype in drivers.c would do. Less clutter. But that's a separate issue to the patches and can be dealt with after this patch has gone in. -- Ø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] How 2 build with new Jim???
Hi Freddie, there has been a fair amount of emails going back and forth, but I like your suggestion here: This mechanism allows to use 3 options: 1. No parameter specified, no jumtcl directory in OpenOCD source tree = use jimtcl library that is installed in the system 2. No parameter specified, jimtcl directory present in OpenOCD source tree = build jimtcl before OpenOCD, use the library in OpenOCD 3. Path to jimtcl library specified = use it in OpenOCD. That's the way gcc handles dependancies like MPFR, GMP, PPL, etc. (or at least I think it does it this way [; ) 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] lpc3131 and Actel FPGA chain programming.
Andrew Leech wrote: two typical ways of using a SVF on a chain, either the SVF file has to be generated to know about the chain or the jtag software has to be aware of the chain. Yeah, makes sense. There's specific HDR and similar commands in svf to define these paddings. Can you say more about them? Did you study the SVF output by FlashPro? It would be interesting to diff a failing SVF with a working one. 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? 3 minutes is also really slow imo, but it is what it is because of how the simple interfaces work. I've ranted enough about that before. The basic openocd command then for me are simply: source [find interface/luminary-icdi.cfg] # My programmer source [find target/lpc3131.cfg] # This is now in mainline :) jtag_khz 6000 # Going to try to optimise this later... reset_config srst_only srst_pulls_trst # My board's only wired to do this jtag newtap a3p125 tap -irlen 8 -expected-id 0x02a121cf # The FPGA init scan_chain # just to be sure they're connected properly svf Chain_PROGRAM_ARRAY.svf quiet # runs my svf file from flashpro and it sits there quietly for just over 3 minutes before informing me it's all done nicely, and I have a working fpga! When I get a chance I'll make a patch/updates to the wiki page on the svf player to be a bit more explicit on how to use it. Thanks! Maybe another option would be for you to just submit a patch with the above board file for your board, with some comments in it? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Build inline jimtcl
Hi, Started a new thread as the others are getting bogged down. This defaults to building the jimtcl inline - only one configure step required, eg. ./configure --enable-maintainer-mode --with-jim-ext=nvp ... The only limitation is that we have to pass the jim options through openocd. autoconf currently does not allow project specific subconfigure options - this is being looked at. I have also added a temp hack so we do not get warnings due to the jim headers - this will need looking at. For those that like the current behaviour just configure with --disable-internal-jimtcl and build lib manually. tested on usual suspects linux, cygwin and mingw. http://repo.or.cz/w/openocd/ntfreak.git/shortlog/refs/heads/jimtcl Let the comments roll :) Cheers Spen From 2755989d4cef1aacaff62b6aa188ac2cc3cbbc15 Mon Sep 17 00:00:00 2001 From: Spencer Oliver ntfr...@users.sourceforge.net Date: Fri, 12 Nov 2010 14:12:44 + Subject: [PATCH 2/2] build: add autobuild jimtcl to configure scripts Rather than having to configure/build jimtcl openocd will do this as part of its own build. To use an external jimtcl lib specify disable-internal-jimtcl to the configure step. Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net --- Makefile.am |8 +++- common.mk |7 +++ configure.in| 15 +++ src/Makefile.am |8 +++- 4 files changed, 36 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index 7d42fd3..b31bcea 100644 --- a/Makefile.am +++ b/Makefile.am @@ -9,7 +9,13 @@ nobase_dist_pkgdata_DATA = \ contrib/libdcc/README \ contrib/openocd.udev -SUBDIRS = src doc +if INTERNAL_JIMTCL +SUBDIRS = jimtcl +else +SUBDIRS = +endif + +SUBDIRS += src doc EXTRA_DIST = \ Doxyfile.in \ diff --git a/common.mk b/common.mk index d2273d7..644aa84 100644 --- a/common.mk +++ b/common.mk @@ -3,3 +3,10 @@ AM_CPPFLAGS = -I$(top_srcdir)/src \ -I$(top_builddir)/src \ -DPKGDATADIR=\$(pkgdatadir)\ + +# HAVE_NO_AUTOCONF is a temp hack to build jimtcl inline +if INTERNAL_JIMTCL +AM_CPPFLAGS += -I$(top_srcdir)/jimtcl \ + -I$(top_builddir)/jimtcl \ + -DHAVE_NO_AUTOCONF +endif diff --git a/configure.in b/configure.in index a15b80a..23e0ff5 100644 --- a/configure.in +++ b/configure.in @@ -2,6 +2,8 @@ AC_PREREQ(2.60) AC_INIT([openocd], [0.5.0-dev], [OpenOCD Mailing List openocd-development@lists.berlios.de]) AC_CONFIG_SRCDIR([src/openocd.c]) +#AC_CONFIG_AUX_DIR([.]) +#AC_CONFIG_SUBDIRS([jimtcl]) AM_INIT_AUTOMAKE([-Wall -Wno-portability dist-bzip2 dist-zip]) AM_MAINTAINER_MODE @@ -486,6 +488,9 @@ AC_ARG_ENABLE(minidriver_dummy, AS_HELP_STRING([--enable-minidriver-dummy], [Enable the dummy minidriver.]), [build_minidriver_dummy=$enableval], [build_minidriver_dummy=no]) +AC_ARG_ENABLE(internal-jimtcl, + AS_HELP_STRING([--enable-internal-jimtcl], [Enable internal jimtcl]), + [use_internal_jimtcl=$enableval], [use_internal_jimtcl=yes]) build_minidriver=no AC_MSG_CHECKING([whether to enable ZY1000 minidriver]) @@ -761,6 +766,14 @@ else AC_DEFINE(BUILD_BUSPIRATE, 0, [0 if you don't want the Buspirate JTAG driver.]) fi +if test $use_internal_jimtcl = yes; then + if test -d $srcdir/jimtcl; then +AC_CONFIG_SUBDIRS([jimtcl]) + else +AC_MSG_ERROR([jimtcl not found, run git submodule init and git submodule update.]) + fi +fi + #-- Deal with MingW/Cygwin FTD2XX issues if test $is_win32 = yes; then @@ -1067,6 +1080,8 @@ AM_CONDITIONAL(BITQ, test $build_bitq = yes) AM_CONDITIONAL(MINIDRIVER, test $build_minidriver = yes) AM_CONDITIONAL(MINIDRIVER_DUMMY, test $build_minidriver_dummy = yes) +AM_CONDITIONAL(INTERNAL_JIMTCL, test $use_internal_jimtcl = yes) + # Look for environ alternatives. Possibility #1: is environ in unistd.h or stdlib.h? AC_MSG_CHECKING([for environ in unistd.h and stdlib.h]) AC_COMPILE_IFELSE([ diff --git a/src/Makefile.am b/src/Makefile.am index 1f29d71..ecd5425 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -20,7 +20,13 @@ MAINFILE = main.c endif openocd_SOURCES = $(MAINFILE) -openocd_LDADD = libopenocd.la -ljim +openocd_LDADD = libopenocd.la + +if INTERNAL_JIMTCL +openocd_LDADD += $(top_builddir)/jimtcl/libjim.a +else +openocd_LDADD += -ljim +endif libopenocd_la_SOURCES = \ hello.c \ -- 1.7.1 From 2b2378a351c1e4079ab7d012d8fe3b5cac83ccf7 Mon Sep 17 00:00:00 2001 From: Spencer Oliver ntfr...@users.sourceforge.net Date: Fri, 12 Nov 2010 11:41:55 + Subject: [PATCH 1/2] build: add common.mk Rather than specifying common makefile variables move them all to a common.mk. Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net --- common.mk|5 + src/Makefile.am |8 ++-- src/flash/Makefile.am|6 ++ src/flash/nand/Makefile.am |4 +--- src/flash/nor/Makefile.am|4 +---
Re: [Openocd-development] How 2 build with new Jim???
/ By default OpenOCD should build the Jim Tcl submodule // automatically, but there should be an option to use the // installed Jim Tcl. // // I disagree strongly with this. // // Moving Jim out into a separate package means that it should also be // treated as a separate package. (Which it is, so it makes perfect sense!) // / [snip lots of detail about building] I think all this misses the point that *right now* people are trying to build openocd from git and failing. This means there is a problem which needs to be fixed. I don't think telling people to go create (.e.g.) cygwin projects to solve their problem is going to be popular. Yes, you're right! By experience, 95% OpenOCD Windows users use cygwin to build their own openocd.exe for Windows. Then they use their openocd.exe on Windows System. So, Cygwin is used in the build process only. For Linux and Mac the build process is a little bit easier, that's good. But the advantage of Cygwin is to force us to learn more about dynamic / static dependency, since you build and use openocd server on two 'different' systems. Also, a lot of users are building openocd from git now, since the release are too old - many improvements every days. Many new features every weeks. But that's is not so bad, since more users are testing the last new features ... Regarding TCL, it should be used as easy user interface only and not be used as algorithm description? The other questions are : Does JimTCL mature enough to be extern to OpenOCD (get from git at any build)? Does OpenOCD really will integrated the new features of JimTCL? Does the basic functions of actual JimTCL will suffice for 95% of our TCL task? I am for having : - the source of JimTCL in the git OpenOCD directory (some kB !!!) - each release of OpenOCD has it own JIMTCL source release inside, - to never use JimTCL for any thing else than user interface. - a review of all of this with a more mature JimTCL and a more mature openocd. Laurent http://www.amontec.com ___ 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 12/11/2010 14:31, Spencer Oliver wrote: Hi, Started a new thread as the others are getting bogged down. This defaults to building the jimtcl inline - only one configure step required, eg. ./configure --enable-maintainer-mode --with-jim-ext=nvp ... The only limitation is that we have to pass the jim options through openocd. autoconf currently does not allow project specific subconfigure options - this is being looked at. I have also added a temp hack so we do not get warnings due to the jim headers - this will need looking at. As mentioned above we are currently adding a hack so jimtcl builds inline - this is fine for the standard configure/make case. 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. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
Freddie Chopin wrote: I like to use OpenOCD with just command-line parameters .. Yes VERY cool, and a part of the success of OpenOCD ! So we have to keep it that way! I don't think that anyone has ever protested against this. Personally I don't like this way of running openocd at all, but since some do of course it should continue to work. Again, noone has protested against this. Maybe you received little input on your suggestion, but that can also mean that others are thinking about it and have not decided yet. That's the case for me at least. Having cfg files for ALL supported targets in one solution, and I'm willing to maintain such list for microcontrollers (arm7 and cortex-m3)... Having REAL generic family config files is another solution, but that's not as user friendly as the first solution... In your use case. But in my use case files covering more devices are more user friendly, since the same config file can be used for different projects using a slightly different target from one family. My first impression from openocd was that the target config files mapped onto physical parts, which made sense to me, and I don't think the fundamental thinking has really changed just because one or two family files have been added. (e.g. stellaris) However, from many other projects I have also seen lots of times that people are very stupid or lazy when they want to add new support which is very similar to existing support, and it is very easy to copy and paste, which I find unacceptable if refactoring of some common parts could be done. The more copypaste we already distribute the more people will create, which is something I think should be looked out for. The way to avoid this is to have base config files for families that have common settings, and per-target files which only have very few settings specific for the target. Call it object orientation if that makes you happy, though I hate that term. :) Now, OpenOCD is becoming more more difficult to build (with the dependency of external tools like JimTCL Laurent, I'm really sorry that you are not comfortable with handling a dependency for OpenOCD, but that is absolutely not a reason to keep a copy of Jim within OpenOCD. I think you can mitigate your problem by helping with integration of the packages into a package distribution that is useful for you. I think you indicated that you like to use Cygwin? It should be really easy to add a Cygwin package for Jim, which eliminates your problem with handling a dependency. and more and more difficult to use with changing System Reset idea What idea? Seriously? What are you talking about? The code that has been added does something in some way. We should be happy that it works at all, and of course work on improving it. The very definition of the open source concept is that if things do not work the way we would like them to, then we have the power to fix that. Complaining is not really so fruitful. If we do not keep the openocd Easy to use, we will certainly kill it, You read my mind (; This negative attitude is incredible! Why are you in the project at all if you do not feel that it is useful for you in some way and/or that you may be able to help improve it? Please stop complaining, that's just an absolute waste of time! Please instead work on how to move forward. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
Spencer Oliver wrote: Shouldn't the code assume that this standard mechanism works as the standard says? The standard as you call it says the behaviour is implementation defined for both. That's very clear for me.. The solution in OpenOCD will then be to assume nothing, and always require cm3 targets to specify which soft-reset method to use. I also think that it would be good to have a check for this in openocd, and make it a fatal error so that openocd simply can not run without the required settings in place. It even goes on to state the following: Debuggers must only use VECTRESET when the core is halted, otherwise the effect is UNPREDICTABLE. openocd needs to also respect this, of course. I also want to get an simple easy reset system working. I don't believe that anyone does not. Then as i mentioned before we need the be aware of what cores support the various reset modes and enable that in the various configs. Yes. The default option should be the safe option an *all* cores. Is there one? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
The default option should be the safe option an *all* cores. Is there one? VECTRESET is reliable from all cores i have tested - which is pretty much all available/nda cm3 cores. It just has the negative that it is core only reset. I am happy todo some work on this - finding the spare time is the issue. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
Freddie Chopin wrote: My perception of the situation is strongly the opposite. There is no policy, relax, there is just people working together making something generic that works. This is a difficult task. I cannot agree, as there were many discussions about whether reset_config should be placed in target file. I subscribed after those discussion, and it seems to me that we continue to learn new things about reset, which means that the code will change too. Where to place a particular setting could easily turn into bikeshedding, so I can understand if at some point in that discussion a decision was made to do things in some particular way. I don't think that means that it will never change. For me it should, but for the majority of OpenOCD maintainers it shouldn't and it won't be. Please stop talking about how the future is hopeless for you! If there is a good reason and a clean patch then anything and everything will change. Maybe things need to get a little worse before they can get a lot better. I think we're still learning about cm3. Sure, but every maintainer has different opinion on what is right and what is better, that's why nothing get's changed I would tend to disagree with that. From experience with many different projects I know that also those who are considered maintainers will not neccessarily *have* an opinion all the time. However, I have noticed that they generally like to be thorough, I am like that too, which means that learning what is right or best can take time. Making experiments, maybe in a branch, can be helpful, but if there is not very active testing then the motivation for that will be somewhat limited. If the goal is to steadily improve the codebase then potentially many large changes will be neccessary to add something like cm3 support, and that will take time. and the status quo will be here forever. Very optimistic outlook. You are already changing status quo by participating in this discussion, please remember that. IMO haveing target file for every supported chip (my recent proposal) is very good and _very_ user-friendly, I tend to agree with you that it is a good approach. I think I wrote so already. I offered to do that, but maintainers were not interested, Really? As in it was expressed that your idea was undesirable? If you simply get no feedback that is not a protest. It may just be that people are thinking about the change. so this mix of family-generic (stm32, stellaris) and target-specific (lpc2103, lpc2148, at91sam7sx, at91sam7se, ...) files will probably be here forever. I don't think this is a bad thing. I would want more family files, with the stuff that is really common for that family, and then target files with stuff that is specific for the targets. The latter should e.g. not really have any if statements, that would be in a family file. Target files would also be pretty short. Probably just a few lines. Completely off-topic: sometimes I think, that open-source projects are just a cover-up made by people working for big companies Sorry, this is a bit silly. I can understand that open source projects are immensely frustrating if there is some kind of incompatibility, be it attitude or philosophy or even trivial stuff like coding style. This things may seem trivial, but imagine that someone produces a patch that adds functioning support for SWD in OpenOCD and that will not be accepted, because the lines are too long... Personally I can not imagine this scenario at all. It is absolutely foreign to me. I think it is a really unneccessary mistake to make for someone who wants to get involved with an open source project. It is important to remember that the person doing this has failed to work *with* or *in* the project. They did their work on the side, and then suggested it for inclusion. This is everyone's prerogative, but it comes with significant risk - *especially* if one is new to the project. When joining any group it's important to fit in. If the contributor you describe above has made no effort at all to learn about e.g. the project coding style before submitting the patch, then I consider the contributor to be clearly at fault. If an effort was made to learn about the coding style but no response was given, then instead the project is clearly at fault. It's very important to help people with what they need in order to contribute. If effort was made to learn about coding style and there was a good response, but the contributor still submits a patch which goes against the coding style, there's instead a problem of communication or understanding, which are both very very difficult to deal with. A completely different class of problem. Noone is clearly at fault and how to resolve the situation depends on everyone involved. Quite complicated. Of course the latter is also incredibly frustrating for everyone involved. I have first hand experience. I also completely understand that not everyone
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
Spencer Oliver wrote: The default option should be the safe option an *all* cores. Is there one? VECTRESET is reliable from all cores i have tested - which is pretty much all available/nda cm3 cores. Aha! What about the 'implementation defined' part though? It just has the negative that it is core only reset. So our choices are basically: 1. fall back to VECTRESET in case of no other information or 2. declare VECTRESET useless Do you think it could be useful? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 2010-11-12 17:46, Laurent Gauch wrote: I think you indicated that you like to use Cygwin? I do not like Cygwin at all, but I HAVE TO use it ;-( to build openocd on Windows I don't build OpenOCD on Windows, but rather cross-compile it on Linux, which I actually have in a virtual machine just for that purpose (; because a lot of users still want to use openocd on Windows. Ignoring the suggestion, that users should change OS to use OpenOCD, I would just like to remind about my builds of releases and development versions that are posted on my website http://www.freddiechopin.info/index.php/en/download/category/4-openocd http://www.freddiechopin.info/index.php/en/download/category/10-openocd-dev The number of downloads speaks for itself. So actually there is no need for 99% of users to build OpenOCD themselves for Windows. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
David Brownell wrote: --- On Fri, 11/12/10, Freddie Chopin freddie_cho...@op.pl wrote: it's hard to imagine a chip that has no srst, As for boards or JTAG adapters without nSRST, no imagination is required; I have production boards of both flavors. Very true, but I think part of the current confusion is due to combination of reset properties of CPU cores and reset properties of boards and interfaces into the same variable, which I think we must avoid going forward. that option can be removed Shouldn't be, though; that'd be very unwise. I think the point is that we should give openocd the information it needs so that it can know when srst is really usable, and not. I completely agree with the model Freddie outlined, of having capabilities for each component involved, and openocd finding the cross-section of those capabilities. I think we should try to take small steps in that direction. Having a specific soft-reset config might be a good first step. //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 Fri, 11/12/10, Peter Stuge pe...@stuge.se wrote: I'm not thrilled about having this information local in the spearsmi Like generic SPI and SPI-flash layers. The flash support shouldn't be SPEAr-specific in the least. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 2010-11-12 18:27, Peter Stuge wrote: David Brownell wrote: As for boards or JTAG adapters without nSRST, no imagination is required; I have production boards of both flavors. Show my an example of any _normal_ JTAG interface that does not have srst? As for the second case, OpenOCD's main purpose is debugging, not programming, so production boards are not very interesting here. Shouldn't be, though; that'd be very unwise. What's the purpose of that option? If user desires a reset, best reset method should be used, and there is no better reset method than hardware SRST reset. If one wishes to use only software resets, than one can remove reset_config command or change it to none - now we have two commands that overlap. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
Freddie Chopin wrote: On 2010-11-12 18:27, Peter Stuge wrote: David Brownell wrote: As for boards or JTAG adapters without nSRST, no imagination is required; I have production boards of both flavors. Show my an example of any _normal_ JTAG interface that does not have srst? I'm sure there are many stupid interfaces like that. We should still be able to use them as well as possible with their limited capabilities.. As for the second case, OpenOCD's main purpose is debugging, not programming, so production boards are not very interesting here. I disagree there, since openocd can easily be automated and customized I think it is also useful for programming. (E.g. the NXP+FPGA chain from just a few days ago.) But it doesn't change our problem; we need a data model that allows a meaningful decision tree in openocd. Limitations of one board or interface should not affect another with more capabilities. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] A word on the process for making changes to OpenOCD
I see there are some lively debates now and as a maintainer, it just isn't possible to dive into every discussion. My approach to this, is to let discussions run their course before applying patches. Usually there will be a flurry of posts, some heated, and then usually after a week or so when everybody has had their say and tempers cool, then someone will come forward with a patch that satisfies everybody as a step in the right direction that is enough of an improvement on the current situation that it merits merging. When this happens, then the community is functioning IMHO. A more dysfunctional case is when there is a lot of posts, much complaining, heated replies and no patch in sight. Oftentimes all that is required is a bit of patience to wait for that patch. -- Ø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] STM32 reset_config
Show my an example of any _normal_ JTAG interface that does not have srst? Depends entirely on what you mean by normal, doesn't it? All I can say is that I've come across non-prototype boards that don't rely on that signal, and thus don't provide JTAG support for it. That is, boards targetted at software developers, so normal in that sense ... and produced in volumes of at least hundreds if not much more. production boards are not very interesting here. You're reading the wrong things into that word. Production contrasts in my mind with one-off prototype ... a development board can be production, and many are. There's also embed-in-end-user-product type production boards, that may not even have JTAG. (Maybe odd form factors, extremely size and cost reduced, and so forth. That's not what I was describing. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 11/12/2010 06:40 PM, Freddie Chopin wrote: Show my an example of any _normal_ JTAG interface that does not have srst? As for the second case, OpenOCD's main purpose is debugging, not programming, so production boards are not very interesting here. At least the Xilinx JTAG cables have no reset outputs, and I think the Altera cables are in the same category. Classical JTAG only needs four wires, so assuming that every JTAG cable should have some kind of reset capability is plain wrong. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 12/11/2010 16:26, Peter Stuge wrote: Spencer Oliver wrote: The default option should be the safe option an *all* cores. Is there one? VECTRESET is reliable from all cores i have tested - which is pretty much all available/nda cm3 cores. Aha! What about the 'implementation defined' part though? It will always reset the core - what else is reset depends on the implementation. It just has the negative that it is core only reset. So our choices are basically: 1. fall back to VECTRESET in case of no other information or 2. declare VECTRESET useless a reset-init script and vectreset is the only option for some cores - the latest luminary devices for example. I thin we need scripts to signal to openocd what the target supports and go from there. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Automatic detection of debugbase for cortex A8
On Sat, Nov 6, 2010 at 8:42 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
I've merged Marek's work:
http://repo.or.cz/w/openocd/cortex.git
I'm pleased not only with the result, but how the set of patches
came about through a great discussion on the list and
improvement of Marek's original solution!
(I haven't actually been able to try it, though it looks great
to me, and it is reported as working.)
--
Ø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
This patch breaks debugging on the DM37x. It appears that the debug
base and APID is not sufficient to identify problematic processors
since the DM37x on the Beagleboard XM incorrectly passes the checks in
arm_adi_v5.c:
for (i = 0; i sizeof(broken_cpus)/sizeof(struct broken_cpu); i++)
if (broken_cpus[i].dbgbase == dbgbase
broken_cpus[i].apid == apid) {
LOG_WARNING(Found broken CPU (%s), trying to fixup
ROM Table location from 0x%08x to 0x%08x,
broken_cpus[i].model, dbgbase,
broken_cpus[i].correct_dbgbase);
dbgbase = broken_cpus[i].correct_dbgbase;
break;
}
Is there another way that these problematic CPUs can be identified?
-Karl
___
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:27 AM, David Brownell davi...@pacbell.net wrote: --- On Fri, 11/12/10, Peter Stuge pe...@stuge.se wrote: I'm not thrilled about having this information local in the spearsmi Like generic SPI and SPI-flash layers. The flash support shouldn't be SPEAr-specific in the least. Understand your comments. I agree that the table could be shared between SPEAr SMI and a generic SPI or SPI-flash framework. But I think this could be the only common part. AFAIK, SPI flash is not accessible in CPU memory space directly, but requires the driver to copy to RAM the flash content. This is stated also in OpenOCD documentation, chapter 12. But, SMI controller is not a generic SPI interface (some devices in SPEAr family also provide a separate SPI controller, keeping SMI for flash only). SMI is a dedicated HW accelerator that hides the SPI protocol and maps on-the-fly the content of the SPI flash in the CPU memory space. This makes SMI + SPI flash similar to a parallel NOR device, and also makes the driver fitting in the generic NOR framework of OpenOCD. I cannot use an explicit SPI framework, since SPI is hidden inside the SMI HW. The SMI has some limitation while choosing a flash device. The documentation reports the list of mandatory SPI commands codes that the flash have to support, since such values are hardcoded in the controller and cannot be changed. So, the table above does not lists all the possible SPI devices, but only a subset of flashes compatible with SMI accelerator. If some other target device has a SPI flash controller with similar characteristic, than would be interesting to compare them and look for common code. In the mean time, I think the table could either be in current file or in a separate one. Would not be difficult to review it later on. Best Regards Antonio Borneo ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
