summaryrefslogtreecommitdiffstats
path: root/flashrom.c
diff options
context:
space:
mode:
authorCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>2010-03-08 00:42:32 +0000
committerCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>2010-03-08 00:42:32 +0000
commite8e369fcc38b374e8385e3415335bfcb87deb55f (patch)
treeb0222eaf1d728eda3c988f504f6dd1d0fb5b3694 /flashrom.c
parent7f0c3ec56b794313b8d23346f8b75bee711c739d (diff)
downloadast2050-flashrom-e8e369fcc38b374e8385e3415335bfcb87deb55f.zip
ast2050-flashrom-e8e369fcc38b374e8385e3415335bfcb87deb55f.tar.gz
Write granularity is chip specific
The following write granularities exist according to my datasheet survey: - 1 bit. Each bit can be cleared individually. - 1 byte. A byte can be written once. Further writes to an already written byte cause the contents to be either undefined or to stay unchanged. - 128 bytes. If less than 128 bytes are written, the rest will be erased. Each write to a 128-byte region will trigger an automatic erase before anything is written. Very uncommon behaviour. - 256 bytes. If less than 256 bytes are written, the contents of the unwritten bytes are undefined. Note that chips with default 256-byte writes, which keep the original contents for unwritten bytes, have a granularity of 1 byte. Handle 1-bit, 1-byte and 256-byte write granularity. Corresponding to flashrom svn r927. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Sean Nelson <audiohacked@gmail.com> Acked-by: David Hendricks <dhendrix@google.com>
Diffstat (limited to 'flashrom.c')
-rw-r--r--flashrom.c61
1 files changed, 61 insertions, 0 deletions
diff --git a/flashrom.c b/flashrom.c
index 03d3bd5..6a91089 100644
--- a/flashrom.c
+++ b/flashrom.c
@@ -620,6 +620,67 @@ out_free:
return ret;
}
+/**
+ * Check if the buffer @have can be programmed to the content of @want without
+ * erasing. This is only possible if all chunks of size @gran are either kept
+ * as-is or changed from an all-ones state to any other state.
+ * The following write granularities (enum @gran) are known:
+ * - 1 bit. Each bit can be cleared individually.
+ * - 1 byte. A byte can be written once. Further writes to an already written
+ * byte cause the contents to be either undefined or to stay unchanged.
+ * - 128 bytes. If less than 128 bytes are written, the rest will be
+ * erased. Each write to a 128-byte region will trigger an automatic erase
+ * before anything is written. Very uncommon behaviour and unsupported by
+ * this function.
+ * - 256 bytes. If less than 256 bytes are written, the contents of the
+ * unwritten bytes are undefined.
+ *
+ * @have buffer with current content
+ * @want buffer with desired content
+ * @len length of the verified area
+ * @gran write granularity (enum, not count)
+ * @return 0 if no erase is needed, 1 otherwise
+ */
+int need_erase(uint8_t *have, uint8_t *want, int len, enum write_granularity gran)
+{
+ int result = 0;
+ int i, j, limit;
+
+ switch (gran) {
+ case write_gran_1bit:
+ for (i = 0; i < len; i++)
+ if ((have[i] & want[i]) != want[i]) {
+ result = 1;
+ break;
+ }
+ break;
+ case write_gran_1byte:
+ for (i = 0; i < len; i++)
+ if ((have[i] != want[i]) && (have[i] != 0xff)) {
+ result = 1;
+ break;
+ }
+ break;
+ case write_gran_256bytes:
+ for (j = 0; j < len / 256; j++) {
+ limit = min (256, len - j * 256);
+ /* Are have and want identical? */
+ if (!memcmp(have + j * 256, want + j * 256, limit))
+ continue;
+ /* have needs to be in erased state. */
+ for (i = 0; i < limit; i++)
+ if (have[i] != 0xff) {
+ result = 1;
+ break;
+ }
+ if (result)
+ break;
+ }
+ break;
+ }
+ return result;
+}
+
/* This function generates various test patterns useful for testing controller
* and chip communication as well as chip behaviour.
*
OpenPOWER on IntegriCloud