dediprog: tremendously improve performance on SF600 by ignoring the spec
The solution was discovered in a collaborative bug hunt with testing done by
David Hendricks. The actual culprit was found by Urja Rannikko by comparing
vanilla flashrom with David's version in chromiumos.
Corresponding to flashrom svn r1933.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Tested-by: David Hendricks <dhendrix@chromium.org>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
diff --git a/dediprog.c b/dediprog.c
index 454a72d..6a9b9ae 100644
--- a/dediprog.c
+++ b/dediprog.c
@@ -694,6 +694,14 @@
if (readcnt == 0) // If we don't require a response, we are done here
return 0;
+ /* The specifications do state the possibility to set a timeout for transceive transactions.
+ * Apparently the "timeout" is a delay, and you can use long delays to accelerate writing - in case you
+ * can predict the time needed by the previous command or so (untested). In any case, using this
+ * "feature" to set sane-looking timouts for the read below will completely trash performance with
+ * SF600 and/or firmwares >= 6.0 while they seem to be benign on SF100 with firmwares <= 5.5.2. *shrug*
+ *
+ * The specification also uses only 0 in its examples, so the lesson to learn here:
+ * "Never trust the description of an interface in the documentation but use the example code and pray."
const uint8_t read_timeout = 10 + readcnt/512;
if (is_new_prot()) {
idx = 0;
@@ -703,6 +711,8 @@
value = min(read_timeout, 0xFF); // Possibly two bytes but we play safe here
}
ret = dediprog_read(CMD_TRANSCEIVE, value, idx, readarr, readcnt);
+ */
+ ret = dediprog_read(CMD_TRANSCEIVE, 0, 0, readarr, readcnt);
if (ret != readcnt) {
msg_perr("Receive SPI failed, expected %i, got %i %s!\n", readcnt, ret, libusb_error_name(ret));
return 1;