summaryrefslogtreecommitdiffstats
path: root/sb600spi.c
diff options
context:
space:
mode:
authorCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>2009-09-05 02:30:58 +0000
committerCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>2009-09-05 02:30:58 +0000
commitf38431a5b23e578cff1299b8d69e7d650c060b60 (patch)
tree293fe367a94034d5b17d622c33e0365ec1a9b871 /sb600spi.c
parentc04ee22c7006d6e006086c40651b8761cea0fbfc (diff)
downloadflashrom-f38431a5b23e578cff1299b8d69e7d650c060b60.tar.gz
flashrom-f38431a5b23e578cff1299b8d69e7d650c060b60.tar.bz2
flashrom-f38431a5b23e578cff1299b8d69e7d650c060b60.zip
Store block sizes and corresponding 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]; Corresponding to flashrom svn r719. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Stefan Reinauer <stepan@coresystems.de>
Diffstat (limited to 'sb600spi.c')
-rw-r--r--sb600spi.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/sb600spi.c b/sb600spi.c
index c853f420e..0738a86e1 100644
--- a/sb600spi.c
+++ b/sb600spi.c
@@ -55,7 +55,7 @@ int sb600_spi_write_1(struct flashchip *flash, uint8_t *buf)
spi_disable_blockprotect();
/* Erase first */
printf("Erasing flash before programming... ");
- if (flash->erase(flash)) {
+ if (erase_flash(flash)) {
fprintf(stderr, "ERASE FAILED!\n");
return -1;
}