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