On Wed, Mar 10, 2010 at 12:28 AM, David Brownell <[email protected]> wrote: > 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? I'm using CFI NOR flash on ARM926ejs. This configuration uses arm_blank_check_memory() in src/target/armv4_5.c and is common to many other targets with NOR flashes (not only CFI).
>> 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...) Yes, could be. I'm still reading the code, there, >> 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
