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] [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] [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] [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] [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] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
Freddie Chopin wrote: If no SRST pin is available, Cortex-M3 soft-reset is required, How common is this case? so use SYSRESETREQ by default. Default instead of SRST, or default instead of VECTRESET? //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-11 17:51, 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? so use SYSRESETREQ by default. Default instead of SRST, or default instead of VECTRESET? Instead of VECTRESET, which does not reset peripherals. If SRST is available, no soft-reset is required. 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.
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? so use SYSRESETREQ by default. Default instead of SRST, or default instead of VECTRESET? Instead of VECTRESET, Ok. If SRST is available, no soft-reset is required. Of course. What decides on the code path? //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 11/11/2010 11:00, Freddie Chopin wrote: Hi! This patch changes the default behaviour of Cortex-M3 soft-reset. More details can be found in thread STM32 reset_config. I've tested that with STM32 - everything works fine, peripherals are reset as they should be (with standard cfg files). 4\/3!! I disagree with this patch as SYSTEMRESET is not supported as expected on all cores. As explained before LPC17xx do not support it. Some variants of the lm3 core will fail, the same goes for some stm32 devices i have tested. I still believe the best way is for each core to state that it supports SYSTEMRESET over VECTRESET in the cfg file. 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 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... 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. 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. 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] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
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? As explained before LPC17xx do not support it. So lpc17xx.cfg file should force VECTRESET. Some variants of the lm3 core will fail That's why stellaris.cfg forces VECTRESET for them. the same goes for some stm32 devices i have tested. All STM32 that I had in hand support SYSRESETREQ without any problems, so why should STM32 users be forced to edit cfg files? I still believe the best way is for each core to state that it supports SYSTEMRESET over VECTRESET in the cfg file. LPC2xxx supposedly cannot be reset into halted mode (because SRST pulls TRST) - should ARM7 control functions assume that as a default? Do they? So why does Cortex-M3 assume that something is broken as a default? 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.
Freddie Chopin wrote: How common is what? Lack of SRST? Yes? For me such situations are almost impossible, Impossible? Weird measure of common. :) but some strange and bizarre policy makes default target file for stm32 tell OpenOCD there is no reset at all... 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. 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... Maybe things need to get a little worse before they can get a lot better. I think we're still learning about cm3. 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. And the fact that projects to a high degree are based on voluntary contributions means that it can be basically impossible to get something done the way you like unless you do it yourself. I am not complaining that *you* do not contribute here, I mean this completely generally. I also completely understand that not everyone can do the changes themselves, but it's also important to remember that those who selflessly do want to contribute code changes that will help others have very limited resources, so it might take time. Using the program is also very important, I belive that testing and bug reports is the only way to make significant progress.. And documentation, and training for others, and so on.. Just remember that this is really just piece of sh*t software that we are hacking on to make it do a decent job. It is still good enough to sell products based on, and sometimes it's many many times better than proprietary products, but it is still not that amazing. Very little software is. Fixing that is of course a huge task, but we all want to make things better and try to help as best we can. If SRST is available, no soft-reset is required. Of course. What decides on the code path? I don't understand the question, Sorry, it was unclear. I meant to ask how openocd knows to use SRTS or soft-reset and if soft-reset then how it knows to use SYSRESETREQ or VECTRESET. I guess it's all target and board config files. 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 What cm3 reset method would that be, for example? C code in OpenOCD? 3. chip resets available, no cortex-m3 reset method specified - use SRST Ok. 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.) Uh? So the cm3 reset method is not in C, but can be set to SRST? 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? I think this makes sense. If SYSRESETREQ is the standard and it is more complete then that should be the default, and those who don't support it can spec a degraded reset functionality if that's the best that can be done. I still believe the best way is for each core to state that it supports SYSTEMRESET over VECTRESET in the cfg file. I guess this is what I was asking about - how common are the two? Maybe it makes the most sense to always require explicit reset configuration in the config files. LPC2xxx supposedly cannot be reset into halted mode (because SRST pulls TRST) Please *stop* adding to this misconception! I've had to patch both lpc2148.cfg and lpc1768.cfg because someone apparently did not read the chip PDFs before making or changing the config files. It's nonsense. The whole issue is really simple IMO; each level of config file (cm3 vs. lpc1768, arm7 vs. lpc2148, etc) should reflect the accurate settings for that level, and more specific files can override more generic ones as neccessary. It's totally possible that there is no applicable default for cm3 in general, then we just don't spec anything on that level, and we make sure to add a check into openocd so that it screams at the user if no reset config has been made, when cm3 is used. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 2010-11-12 00:05, Peter Stuge 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. For me it should, but for the majority of OpenOCD maintainers it shouldn't and it won't be. 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... 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 and the status quo will be here forever. IMO haveing target file for every supported chip (my recent proposal) is very good and _very_ user-friendly, I offered to do that, but maintainers were not interested, so this mix of family-generic (stm32, stellaris) and target-specific (lpc2103, lpc2148, at91sam7sx, at91sam7se, ...) files will probably be here forever. 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... And the fact that projects to a high degree are based on voluntary contributions means that it can be basically impossible to get something done the way you like unless you do it yourself. I am not complaining that *you* do not contribute here, I mean this completely generally. Agreed, that's obvious, and no one is forcing any of the maintainers to implement someones requests. I also completely understand that not everyone can do the changes themselves, but it's also important to remember that those who selflessly do want to contribute code changes that will help others have very limited resources, so it might take time. We can get back to my previous point. If that someone had produced a monolithic SWD patch, that would also not be accepted, because changes should be incremental, easy, isolated, and so on. But imagine how this contributor would feel when he/she would be told to spend another 100 hours on refactoring the patch that took hin'her 100 hours. I would probably just write love or leave... Just remember that this is really just piece of sh*t software that we are hacking on to make it do a decent job. It is still good enough to sell products based on, and sometimes it's many many times better than proprietary products, but it is still not that amazing. Very little software is. Fixing that is of course a huge task, but we all want to make things better and try to help as best we can. It's not that I don't like OpenOCD, but how is it better than commercial software that allows one to start debug session in 3 clicks (select target model, select debugger, click connect)? This attitude may seem a bit negative, but believe me, that it's exact same attitude that a typical newcomer to ARM's world shows. Sorry, it was unclear. I meant to ask how openocd knows to use SRTS or soft-reset and if soft-reset then how it knows to use SYSRESETREQ or VECTRESET. I guess it's all target and board config files. Clarification: standard command reset_config can define that there are resets present or not. Default is none and that is assumed when no reset_config command is present. new command cortex-m3 reset_config can define reset method for Cortex-M3 core - srst (real reset, only if the signal is available, so reset_config srst is required), sysresetreq (almost-real-reset - resets peripherals) or vectreset (soft-reset that does not reset peripherals). 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 What cm3 reset method would that be, for example? C code in OpenOCD? case 1 is when OpenOCD receives neither reset_config nor cortex-m3 reset_config. case 2 is when OpenOCD reveives reset_config srst / srst_and_trst and cortex-m3 reset_config srst / sysresetreq / vectreset - chip would be reset with a method specified with the latter. 3. chip resets available, no cortex-m3 reset method specified - use SRST Ok. case 3 is when OpenOCD reveives reset_config srst / srst_and_trst but no cortex-m3 reset_config ... - normal reset signal is asserted. 4. no chip resets, cortex-m3 reset method specified
