NOR: add FIXMEs for writing ones

It can invalidate ECC codes, and in general is not guaranteed
to work.  (However on some chips it _appears_ to behave.)  Just
don't do it; don't write in those cases.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This commit is contained in:
David Brownell 2010-01-08 16:47:58 -08:00
parent 12c143d594
commit 296a011db5
2 changed files with 11 additions and 2 deletions

6
TODO
View File

@ -209,6 +209,12 @@ https://lists.berlios.de/pipermail/openocd-development/2009-October/011506.html
- ocl - ocl
- str9xpec - str9xpec
- Don't expect writing all-ones to be a safe way to write without
changing bit values. Minimally it loses on flash modules with
internal ECC, where it may change the ECC.
- NOR flash_write_unlock() does that between sectors
- there may be other cases too
@subsection thelistflashcfi CFI @subsection thelistflashcfi CFI
- finish implementing bus width/chip width handling (suggested by NC) - finish implementing bus width/chip width handling (suggested by NC)

View File

@ -449,9 +449,12 @@ int flash_write_unlock(struct target *target, struct image *image,
break; break;
} }
/* REVISIT This needlessly touches sectors BETWEEN the /* FIXME This needlessly touches sectors BETWEEN the
* sections it's writing. Without auto erase, it just * sections it's writing. Without auto erase, it just
* writes ones; unlikely to destroy data. * writes ones. That WILL INVALIDATE data in cases
* like Stellaris Tempest chips, corrupting internal
* ECC codes; and at least FreeScale suggests issues
* with that approach (in HC11 documentation).
* *
* With auto erase enabled, data in those sectors will * With auto erase enabled, data in those sectors will
* be needlessly destroyed; and some of the limited * be needlessly destroyed; and some of the limited