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

[Pablo Cases]

> > 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).

I'm using a Dediprog SF100 with the newish firmware v5.5.01 (supposedly so that dediprog works on Windows 8.1 computers), so yes I is USB based. Looking at both the USB and SPI traffic it is obvious that the SPI traffic is sparse with a fair amount of delays between the commands (possibly as a result of the USB round trip and the dediprog hardware, but no detailed investigations have been performed it is just a hunch). These communication delays will of course add to the long erase times if multiple commands must be issued sequentially.

> 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.

I have to admit I was a bit lazy here and initially quoted the time reported by the Dediprog Software on Windows when it schedules the 0xc7 Chip Erase command. I have now timed a 0xc7 Chip Erase from flashrom which clocks in at 23 seconds. Looking at both the USB and SPI traffic I can see that the 0xc7 Chip Erase completes after ~9 seconds but flashrom continues on to read all the chip contents for another 12-ish seconds. The Dediprog application does not do this validation which will of course reduce the overall time.

> 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).

That seems like the proper way to do it as it does not assume anything (like my patch does), but it is of course a bigger task to complete :)
I'm ok with this patch going to /dev/null.

Regards,
Pablo