On Friday 18 December 2009, Michael Schwingen wrote:
> David Brownell wrote:
> > Though ... I suppose that just verifying flash writes would
> > catch a number of these problems too.  After all, the main
> > constraint is that zero bits can't turn back to ones...
>   
> Sounds good. Another alternative would be to read the current flash 
> contents, patch in the byte to be written, and then write it back. That 
> way, a single byte at the end of a segment can be written, and nothing 
> is accidentally overwritten.

Writing ones to it, as the current code does, should have the
same "no change" effect ... hence my thought about verification.

Consider what happens if you write to some flash that's not
been erased beforehand.  In most cases, you lose ... 

 
> > Semi-related ... how about the generic NOR patch insisting
> > that erases only apply to whole sectors?  It's not quite
> > the converse of this patch.  This one was perhaps more on
> > the side of paranoia.  That one was concern that the code
> > was certainly doing something destructive, by clobbering
> > data it was told to leave alone.
>   
> Allowing erase only on complete sectors is fine with me, because the 
> damage potential is large, and I see no direct use case where you would 
> specify a partial sector and expect that the whole sector should be erased.

My thought exactly.  I'll commit that change as-is then...

 
> One thing to take care of would be write_image with the erase option: 
> the image will probably not competely fill the last sector, but the 
> erase should not fail in that case.

... and expect some followup bugfixes.  That one, for example,
certainly deserves at least a WARNING whenever it kicks in...

- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to