Flashrom using slowest item from block_erasers list
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
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).
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@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).
participants (2)
-
David Hendricks -
Ryan O'Leary