[flashrom] [PATCH] Reorder block_erasers to favor large block erasers over small block erasers

[Stefan Tauner]

On Thu, 31 Jul 2014 12:08:11 +0000
Pablo Cases <pablo.cases at flatfrog.com> wrote:

> This patch reorders the block_erasers by increasing block count with the assumption that the fewer block erase commands that have to be issued the lower the erase times. E.g. this will favor chip erase instructions (as their block count is 1) even though they are generally listed last in the block_erasers list for each chip in flashchips.c
> 
> As an example this reduces the erase time for a W25Q64.V chip from 14 minutes to 8 seconds as a single Chip Erase (60h) instruction will be used instead of issuing a sequence of 2048 Sector Erase (20h) commands.
> 

Hi Pablo,

i think there is one major problem with this: it breaks partial
updates. If the data on the chip and the data requested (i.e. the data
residing in the file) are equal, flashrom skips the whole write
process. If there are changes, flashrom tries the smallest block size
first and modifies only those blocks that are different. AFAICS your
patch would reverse the order and hence any change would require to
erase and write the flash completely even if only one byte has changed
and the flash chip (and programmer) support smaller blocks.
The partial updates are not only a performance strategy: If some blocks
are write-protected without a (working) way to unlock them your patch
would introduce a regression in the case only unprotected blocks are
to be modified.

Your benchmark seems to measure an extreme case. What programmer do you
use, something USB-based I guess, a bus pirate maybe? Even for that 14
mins seem to be quite slow (almost half a second for one block, which
is btw about the maximum erase time stated in the datasheet, although
that is probably not really the bottleneck).
Also, the 8 seconds are half of the specified typical chip erase
time(!). No idea how you managed to do that. :) I was looking at
revision C of the W25Q64CV datasheet for the timing values.

To sum up: I don't think this is the right way to do this and a proper
implementation would require quite some effort (pre-calculating
necessary erases, estimating the best block eraser(s) to use etc).

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner