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.
Similar issue would be present in any other case when OpenOCD executes some helper-code. 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. 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
