Erase functions with non-expressable block layout

[Carl-Daniel Hailfinger]

Hi,

there are a few chips out there which have an eraseblock layout that can
not be expressed in our current structure. For example, erase functions
which only work in a small region of the chip and which are
undefined/non-functional elsewhere.

We don't have a way to express such constraints (well, I have a design
in mind, but that's something we'd better do post 0.9.2), but losing
that information is not exactly something I want to risk. Just specify
an empty eraseblock layout, and associate the "evil" function with it.
flashrom will issue a diagnostic on debug level SPEW, but flashrom will
run perfectly fine.

Example:

.block_erasers  =
{       
    { /* The working layout */
        .eraseblocks = { {16 * 1024, 8} },
        .block_erase = erase_sector_29f040b,
    }, { /* The weird layout*/
        .eraseblocks = { },
        .block_erase = erase_block_totallyweird_29f040b,
    },      
},

This mail was motivated by the following problem:
On 19.01.2010 00:30, Carl-Daniel Hailfinger wrote:
> On 19.01.2010 00:21, Sean Nelson wrote:
> > On 1/18/2010 2:48 PM, Michael Karcher wrote:
> > > I don't think this is going to work. erase_sector_stm50flw0x0x only
> > > works on the 4K sectors and not on the 64k blocks inbetween, if I read
> > > the datasheet correctly. As I already wrote in the first review:
> > > flashrom is currently unable to represent this architecture (different
> > > block sizes that have to be delete by different commands), so you better
> > > leave it off. Another possible, but a bit hacky, version would be to
> > > check sectorsize in erase_sector_stm50flw0x0x and call
> > > erase_block_stm50flw0x0x if sectorsize is 64*1024.
> >
> > The datasheet doesn't state either way that it wouldn't work on the 5x
> > 64k sectors between the 4k blocks, but I'm just going to remove the
> > sector erasers and leave the function.
>
> Maybe add a comment in flashchips.c for that chip which says the
> structure can't be expressed right now.

Regards,
Carl-Daniel