Skip to content

GitLab

Switch branch/tag
  1. 16 Sep, 2009 1 commit
  3. 05 Sep, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Store block sizes and corresponding erase functions in struct flashchip · f38431a5
      Carl-Daniel Hailfinger authored 
      
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: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarStefan Reinauer <stepan@coresystems.de>
      f38431a5
  5. 02 Sep, 2009 1 commit
  7. 19 Aug, 2009 3 commits
  9. 12 Aug, 2009 5 commits
  11. 10 Aug, 2009 1 commit
  13. 09 Aug, 2009 1 commit
  15. 30 Jul, 2009 1 commit
  17. 23 Jul, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      This is a workaround for a bug in SB600 and SB700 · f8555e24
      Carl-Daniel Hailfinger authored 
      
If we only send an opcode and no additional data/address, the SPI
controller will read one byte too few from the chip. Basically, the
last byte of the chip response is discarded and will not end up in the
FIFO. It is unclear if the CS# line is set high too early as well. That
hardware bug is undocumented as of now, but I'm working with AMD to add
a detailed description of it to the errata.

Add loads of additional debugging to SB600/SB700 init.

Add explanatory comments for unintuitive code flow.

Thanks go to Uwe for testing quite a few iterations of the patch.

Kill the SB600 flash chip status register special case, which was a
somewhat misguided workaround for that hardware erratum.

Note for future added features in the SB600 SPI driver: It may be
possible to read up to 15 bytes of command response with overlapping
reads due to the ring buffer design of the FIFO if the command can be
repeated without ill effects. Same for skipping up to 7 bytes between
command and response.

Corresponding to flashrom svn r661.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarStefan Reinauer <stepan@coresystems.de>
      f8555e24
  19. 22 Jul, 2009 2 commits
  21. 12 Jul, 2009 1 commit
  23. 11 Jul, 2009 1 commit
  25. 10 Jul, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Add SPI multicommand infrastructure · d0478299
      Carl-Daniel Hailfinger authored 
      
Some SPI opcodes need to be sent in direct succession after each other
without any chip deselect happening in between. A prominent example is
WREN (Write Enable) directly before PP (Page Program). Intel calls the
first opcode in such a row "preopcode".

Right now, we ignore the direct succession requirement completely and it
works pretty well because most onboard SPI masters have a timing or
heuristics which make the problem disappear.
The FT2232 SPI flasher is different. Since it is an external flasher,
timing is very different to what we can expect from onboard flashers and
this leads to failure at slow speeds.

This patch allows any function to submit multiple SPI commands in a
stream to any flasher. Support in the individual flashers isn't
implemented yet, so there is one generic function which passes the each
command in the stream one-by-one to the command functions of the
selected SPI flash driver.
Tested-by: default avatarJakob Bornecrantz <wallbraker@gmail.com>

Corresponding to flashrom svn r645.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarJakob Bornecrantz <wallbraker@gmail.com>
      d0478299
  27. 01 Jul, 2009 1 commit
  29. 28 Jun, 2009 1 commit
  31. 24 Jun, 2009 1 commit
  33. 23 Jun, 2009 1 commit
  35. 20 Jun, 2009 1 commit
    • Uwe Hermann's avatar
      Various wiki output changes · a2d05012
      Uwe Hermann authored 
      
 - Move board_info_url struct to print.c, doesn't have to be global.

 - Simplify flashrom.c a bit by moving stuff to print.c.
   Eliminate two now-useless mini-functions in print.c.

 - Add a note that the wiki page contents are semi-automatically generated.

 - Mention date of last wiki page update as well as the flashrom revision
   that was used to generate the wiki output.

 - Also generate list of supported laptops in -z output now.

 - Add some more board URLs.

 - Add a boards_notes[] table to allow for arbitrary footnotes/comments for
   each board in the table. All notes will automatically be turned into
   wiki footnotes with correct numbers and will appear at the end of the
   respective table.

Corresponding to flashrom svn r615.
Signed-off-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      a2d05012
  37. 19 Jun, 2009 1 commit
  39. 18 Jun, 2009 1 commit
  41. 17 Jun, 2009 1 commit
  43. 16 Jun, 2009 2 commits
  45. 15 Jun, 2009 3 commits
  47. 14 Jun, 2009 1 commit
  49. 13 Jun, 2009 1 commit
  51. 12 Jun, 2009 2 commits
  53. 05 Jun, 2009 3 commits

Powered by Integricloud