On Monday 08 March 2010, Antonio Borneo wrote: > Hi Dave, > > your patch below (commit 5fdf9535cef7e43f6e99081b6d1f6bd682184803) > breaks the command "flash erase_check ..." > Such command executes on the target a tiny helper-code on each flash sector. > At each execution the erase status already computed on previous > sectors are deleted by your patch.
Odd ... not in my testing. Is that behavior specific to some flash driver? Or target? > Similar issue would be present in any other case when OpenOCD executes > some helper-code. THis could be related to the ambiguous semantics of one of the target_resume() parameters, which have caused other problems in the past. Basically, not all targets treat the parameters in the same way. (See its doxygen...) > I think the solution should be to discriminate between resume driven > by user and execution forced internally by OpenOCD. > nor_resume() should be called only in former case. That is, you'd like to see the "debug_execution" parameter mean something along the lines of "This is 'Trusted' OpenOCD-internal code", and then not invalidate the cache if that flag is set. Which would add extra and hard-to-enforce semantics to that parameter... or else would render that cache as useless as it was before, since nothing could rely on it. I'm all for resolving the ambiguity in what that parameter means, but doing that would require auditing all callers and implementations, and making a lot of changes... - Dave > > Best Regards, > Antonio Borneo > > On Wed, 3 Mar 2010 13:23:12 -0800 David Brownell <[email protected]> wrote: > > The NOR infrastructure caches some per-sector state, but > > it's not used much ... because the cache is not trustworthy. > > > > This patch addresses one part of that problem, by ensuring > > that state cached by NOR drivers gets invalidated once we > > resume the target -- since targets may then modify sectors. > > > > Now if we see sector protection or erase status marked as > > anything other than "unknown", we should be able to rely > > on that as being accurate. (That is ... if we assume the > > drivers initialize and update this state correctly.) > > > > Another part of that problem is that the cached state isn't > > much used (being unreliable, it would have been unsafe). > > Those issues can be addressed in later patches. > > --- > > Haven't merged this yet. The effect should be slightly > > visible via "flash protect_check" and "flash info" commands; > > basically, once you resume, you'll need to protect_check > > again. > > > > I'm tempted to rename the new routine to "nor_resume()" > > to help nove a way from the bad "all is NOR" assumption... > > > > I'd like to merge this in a few days, to enable various bits of > > cleanup which would use the now-more-valid cached state to avoid > > needless and/or inappropriate flash ops, and finish fixing > > > > http://sourceforge.net/apps/trac/openocd/ticket/11 > > > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
