[openocd-svn] Main OpenOCD repository branch, master, updated. v0.4.0-rc1-70-g296a011

[David B. <dbr...@us...>]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Main OpenOCD repository".

The branch, master has been updated
       via  296a011db5833b8a3258a058e6a805cc5ddb2bfe (commit)
      from  12c143d5948355b3b54c9c0decc779177b22d5d9 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 296a011db5833b8a3258a058e6a805cc5ddb2bfe
Author: David Brownell <dbr...@us...>
Date:   Fri Jan 8 16:47:58 2010 -0800

    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 <dbr...@us...>

diff --git a/TODO b/TODO
index 8fed264..73e4aa7 100644
--- a/TODO
+++ b/TODO
@@ -209,6 +209,12 @@ https://lists.berlios.de/pipermail/openocd-development/2009-October/011506.html
   - ocl
   - 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
 
 - finish implementing bus width/chip width handling (suggested by NC)
diff --git a/src/flash/nor/core.c b/src/flash/nor/core.c
index 01088f3..7e783d4 100644
--- a/src/flash/nor/core.c
+++ b/src/flash/nor/core.c
@@ -449,9 +449,12 @@ int flash_write_unlock(struct target *target, struct image *image,
 				break;
 			}
 
-			/* REVISIT This needlessly touches sectors BETWEEN the
+			/* FIXME This needlessly touches sectors BETWEEN the
 			 * 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
 			 * be needlessly destroyed; and some of the limited

-----------------------------------------------------------------------

Summary of changes:
 TODO                 |    6 ++++++
 src/flash/nor/core.c |    7 +++++--
 2 files changed, 11 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
Main OpenOCD repository