[flashrom] [PATCH] Convert chips to block erasers: ST

[Carl-Daniel Hailfinger]

On 19.01.2010 11:45, Michael Karcher wrote:
> Am Dienstag, den 19.01.2010, 11:36 +0100 schrieb Carl-Daniel Hailfinger:
>   
>>> +				.eraseblocks = {
>>> +					{4 * 1024, 16},  /* sector */
>>> +					{64 * 1024, 5}, /* block */
>>> +					{4 * 1024, 16}, /* sector */
>>> +					{4 * 1024, 16}, /* sector */
>>> +				},
>>> +				.block_erase = NULL,
>>>       
>
>   
>> It might be a good idea to change the line
>>
>> {64 * 1024, 5},
>>
>> to
>>
>> {320 * 1024, -1},
>>
>> once flashrom can deal with negative sizes and interpret them as
>> "function does not apply to this area".
>>     
> I really like that idea, although it may make block walking harder. The
> idea is to have the walking code centralized, so it shouldn't matter
> that much.
>   

Yes, my goal is to have an erase_range function which gets start and
length as parameters and picks an erase function which can do that, or
tells the caller that it the only possible erase is bigger than the
requested erase. That erase_range function would do the block walking in
a manner similar to what we have now.


> On the other hand, things get messy if you have partly overlapping erase
> blocks in different erase functions, but I think this is just a "don't
> do it then" issue. I can't imagine any sane flash chip that would have
> partly overlapping erase blocks.
>   

Heh. Sanity in flash chips? I want to go to that magic place. ;-) But
yes, we can simply refuse to handle such stuff if it ever arises.


>> Or we create a special erase
>> function which does different things based on eraseblock size/location.
>>     
> And don't like this one, as these functions probably get chip specific,
> and currently we are heading to kill chip specific functions, don't we?
>   

Indeed.

Regards,
Carl-Daniel

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