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 <[email protected]> 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). >
_______________________________________________ flashrom mailing list -- [email protected] To unsubscribe send an email to [email protected]
