Flashrom using slowest item from block_erasers list

[Ryan O'Leary]

Flashrom with dediprog is selecting a sub-optimal block_erasers from the
available list.

For example, MX66L51235F in flashchips.c has 4 sizes of block erasers:
4KiB, 32KiB, 64KiB and 64MiB. 4KiB is the default, but also the slowest and
can take 20+ minutes to reprogram a chip. 32KiB and 64KiB are significantly
faster (sometimes up to 10x). 64MiB causes a fault which is a separate
issue entirely.

Currently, I manually edit flashchips.c to comment out the undesired sizes
for this chip (everything except 64KiB), but this can be tedious and not
easy to discover by others.

What would be the best solution here? Would it make sense to submit this
change for this particular chip? I understand there may also be a
speed/wear tradeoff.

I am also interested in the more general case. Do larger erase sizes tend
to reprogram a chip faster? If so, why does flashrom not always use the
larger sizes?

Thanks,
Ryan

[David Hendricks]

Hi Ryan,

  What would be the best solution here? Would it make
sense to submit this change for this particular chip? I understand there may also be a
speed/wear tradeoff.

 I am also interested in the more general case. Do larger erase sizes tend to reprogram a
chip faster? If so, why does flashrom not always use the larger sizes?
Flashrom knows the current contents of the flash chip and the new
contents that will be programmed. So ideally it should
opportunistically use the largest block erase size for any given
chunk, whether it's 4KB or 64KB or the entire chip. The work just
needs to be done to implement that.

Of course things are never quite that simple and we must also check
that it doesn't interfere with chip or programmer enforced write
protection. For example if the chip has certain block ranges
protected, or in the usual Intel platform case with the flash
descriptor regions and permissions (and opmenu stuff).

[Ryan O'Leary]

Thanks David! That is a really good point about the write protection.

I was thinking more about this lately and can't help but feel there would
need to be some type of heuristic involved. For example, consider these
three cases:

1. Only a 4kb chunk changed => Erase that 4kb chunk
2. All the 4kb chunks in a 64kb chunk changed => Erase the 64kb chunk
3. 50% of the 4kb chunks in a 64kb chunk changed => Should the 8 individual
4kb chunks be erased or the whole 64kb chunk?

The 3rd case is where I think there would need to be a heuristic. Thoughts?

- Ryan

On Tue, Nov 19, 2019 at 10:00 PM David Hendricks <david.hendricks(a)gmail.com>
wrote:

  Hi Ryan,

  What would be the best solution here? Would it
make sense to submit this
 change for this particular chip? I understand there may
also be a
 speed/wear tradeoff.
 
 I am also interested in the more general case. Do larger erase sizes
 tend to
reprogram a chip faster? If so, why does flashrom not always use
 the larger sizes?

 Flashrom knows the current contents of the flash chip and the new
 contents that will be programmed. So ideally it should
 opportunistically use the largest block erase size for any given
 chunk, whether it's 4KB or 64KB or the entire chip. The work just
 needs to be done to implement that.

 Of course things are never quite that simple and we must also check
 that it doesn't interfere with chip or programmer enforced write
 protection. For example if the chip has certain block ranges
 protected, or in the usual Intel platform case with the flash
 descriptor regions and permissions (and opmenu stuff).