[coreboot] [PATCH] flashrom: sector-based flashing

[Carl-Daniel Hailfinger]

On 15.06.2009 16:12, Carl-Daniel Hailfinger wrote:
> This is a patch which stores eraseblock sizes and corresponding block
> erase functions in struct flashchip. I decided to fill in the info for a
> few chips to illustrate how this works both for uniform and non-uniform
> sector sizes.
>
> struct eraseblock{
> int size; /* Eraseblock size */
> int count; /* Number of contiguous blocks with that size */
> };
>
> struct eraseblock doesn't correspond with a single erase block, but with
> a group of contiguous erase blocks having the same size.
> Given a (top boot block) flash chip with the following weird, but
> real-life structure:
>
> top
> 16384
> 8192
> 8192
> 32768
> 65536
> 65536
> 65536
> 65536
> 65536
> 65536
> 65536
> bottom
>
> we get the following encoding:
> {65536,7},{32768,1},{8192,2},{16384,1}
>
> Although the number of blocks is bigger than 4, the number of block
> groups is only 4. If you ever add some flash chips with more than 4
> contiguous block groups, the definition will not fit into the 4-member
> array anymore and gcc will recognize that and error out. No undetected
> overflow possible. In that case, you simply increase array size a bit.
> For modern flash chips with uniform erase block size, you only need one
> array member anyway.
>
> Of course data types will need to be changed if you ever get flash chips
> with more than 2^30 erase blocks, but even with the lowest known erase
> granularity of 256 bytes, these flash chips will have to have a size of
> a quarter Terabyte. I'm pretty confident we won't see such big EEPROMs
> in the near future (or at least not attached in a way that makes
> flashrom usable). For SPI chips, we even have a guaranteed safety factor
> of 4096 over the maximum SPI chip size (which is 2^24). And if such a
> big flash chip has uniform erase block size, you could even split it
> among the 4 array members. If you change int count to unsigned int
> count, the storable size doubles. So with a split and a slight change of
> data type, the maximum ROM chip size is 2 Terabytes.
>
> Since many chips have multiple block erase functions where the
> eraseblock layout depends on the block erase function, this patch
> couples the block erase functions with their eraseblock layouts.
> struct block_eraser {
>         struct eraseblock{
>                 unsigned int size; /* Eraseblock size */
>                 unsigned int count; /* Number of contiguous blocks with
> that size */
>         } eraseblocks[NUM_ERASEREGIONS];
>         int (*block_erase) (struct flashchip *flash, unsigned int
> blockaddr, unsigned int blocklen);
> } block_erasers[NUM_ERASEFUNCTIONS];
>
> This patch is an improved version of the patch I sent 7 months ago which
> received favourable reviews back then, but it seems nobody acked it. The
> original version was posted 8 months ago.
>
> The additional improvements are:
> - Chip erase is now simply a block erase with blocklength of the chip size.
> - Cleanups in flashrom.c.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>   

Updated patch against svn HEAD attached.
It has one feature which should help debug an oddity Uwe is seeing.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: flashrom_eraseblocks04.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090616/b2a874d4/attachment.ksh>