[flashrom] [PATCH] Check if an erase is needed to write

[Carl-Daniel Hailfinger]

On 17.09.2009 12:41, Carl-Daniel Hailfinger wrote:
> On 16.09.2009 23:40, Stefan Reinauer wrote:
>   
>> Carl-Daniel Hailfinger wrote:  
>>     
>>> On 16.09.2009 19:07, Stefan Reinauer wrote:
>>>       
>>>> Carl-Daniel Hailfinger wrote:
>>>>         
>>>>> For optimal partial reflashing, we have to find out which parts of the
>>>>> chip can be written without erase. For that, the only criterion (except
>>>>> a limit on the number of writes for very old chips) is whether the write
>>>>> will only clear bits (set them to 0).
>>>>> If (current&new==new) we can skip the erase.
>>>>> If any bit would have to be set to 1, we need to erase.
>>>>>
>>>>>           
>>>> Is that sufficient? Ie is it always ok to skip an erase if we're only
>>>> clearing bits?
>>>>
>>>>         
>>> It depends on the chip, but given that the following appears in the ICH7
>>> and all later datasheets as absolute flash requirement, I'm positive
>>> most current flash chips support it.
>>>
>>> -----------------
>>> The system BIOS and Intel® Active Management Technology firmware usage
>>> models
>>> require that the serial flash device support multiple writes (minimum of
>>> 512 writes) to
>>> a page (256 bytes) without requiring a preceding erase command.
>>> -----------------
>>>
>>>       
>> That means you can theoretically write it twice (2*256 byte writes on an
>> x8 device) without erasing it.
>> I don't think this is something we should rely on.
>>
>> It also says serial flash device, which implies that LPC/FWH might
>> behave differently.
>>
>>     
>
> How should we handle the case where a chip is already erased? Do we
> erase anyway? After all, we can't know if someone already wrote 0xff there.
>   

To summarize: Write granularity is chip specific. The following write
granularities exist according to my datasheet survey:
- 1 bit. Each bit can be cleared individually.
- 1 byte. A byte can be written once. Further writes to an already
written byte cause the contents to be either undefined or to stay unchanged.
- 128 bytes. If less than 128 bytes are written, the rest will be
erased. Each write to a 128-byte region will trigger an automatic erase
before anything is written. Very uncommon behaviour.
- 256 bytes. If less than 256 bytes are written, the contents of the
unwritten bytes are undefined.

Note that chips with default 256-byte writes, which keep the original
contents for unwritten bytes, have a granularity of 1 byte.

This patch covers the 1-bit granularity variant, and since it is not
hooked up anywhere, I think it is a good starting point for implementing
a check for all variants. We will need an additional field in struct
flashchip for the minimum write granularity, though.

An ack would be appreciated. I'm open to adding the explanation above as
comment to the function and/or adding it to the commit message.

Regards,
Carl-Daniel

-- 
Developer quote of the month: 
"We are juggling too many chainsaws and flaming arrows and tigers."