Hi,
starting a new thread for this because it's somewhat orthogonal.
[...] The progress would not be constant in speed (e.g. because reading is usually much faster than writing), and it would sometimes even be non-monotonic (if a write fails, we re-read the whole chip to make absolutely sure we get everything correct thus increasing the total number of bytes to transfer...
That's an internal that I'd really try to avoid to build the progress interface around. Actually I'd like to get rid of this fallback semantic at least in the library version of flashrom_flash_write(). Some reasons why:
* I've seen this fallback (not) working in the following cases:
1. Unreliable connection – fallback made things even worse, usually erasing the whole chip. 2. Wrong flash chip selected – is that a valid use case? 3. Locked opcodes in the programmer – we could just ask the programmer beforehand if it's supposed to work.
* The complex procedure is very far from what someone would expect when he calls a write function.
Instead, the caller could set a hint in the flash context if a specific erase function should be used (to work around issues that shouldn't exist, ahem).
Thoughts?
Nico
-
Nico Huber