1. 23 Dec, 2009 1 commit
  2. 22 Dec, 2009 1 commit
  3. 27 Nov, 2009 1 commit
    • Michael Karcher's avatar
      Use common jedec functionality where appropriate · 1c296ca8
      Michael Karcher authored
      
      The deleted function in en29f002a.c is reintroduced as
      write_by_byte_jedec in jedec.c as it contains no chip-specific
      instructions. It is not yet used in other chip drivers, as key addresses
      (0x2AAA/0x5555) are often specified with less bits. After crosschecking
      datasheets, most of the fixmes can probably be resolved as indicated in
      them, causing significant code reduction.
      
      The common JEDEC code for bytewise programming does not program 0xFF
      at all. The chips that had a dedicated bytewise flash function which
      has been changed to write_jedec_1 thus changed flashing behaviour
      and the "write" test flag has been removed. This applies to: AMD
      Am29F002BB/Am29F002NBB AMD Am29F002BT/Am29F002NBT (TEST_OK_PREW before)
      AMIC A29002B AMIC A29002T (TEST_OK_PREW before) EON EN29F002(A)(N)B EON
      EN29F002(A)(N)T (TEST_OK_PREW before) Macronix MX29F001B (TEST_OK_PREW
      before) Macronix MX29F001T (TEST_OK_PREW before) Macronix MX29F002B
      Macronix MX29F002T (TEST_OK_PREW before) Macronix MX29LV040
      
      Similar analysis should be performed for the read id stuff.
      
      Corresponding to flashrom svn r785.
      Signed-off-by: default avatarMichael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
      Acked-by: default avatarSean Nelson <audiohacked@gmail.com>
      Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      1c296ca8
  4. 26 Nov, 2009 1 commit
  5. 24 Nov, 2009 2 commits
  6. 20 Nov, 2009 1 commit
  7. 14 Nov, 2009 1 commit
  8. 06 Nov, 2009 1 commit
  9. 01 Oct, 2009 1 commit
  10. 25 Sep, 2009 1 commit
  11. 23 Sep, 2009 2 commits
  12. 09 Sep, 2009 1 commit
  13. 05 Sep, 2009 2 commits
    • 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
    • Udu Ogah's avatar
      Update probe timings for dozens of flash chips · c04ee22c
      Udu Ogah authored
      
      Corresponding to flashrom svn r718.
      Signed-off-by: default avatarUdu Ogah <putlinuxonit@gmail.com>
      Acked-by: default avatarStefan Reinauer <stepan@coresystems.de>
      Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      c04ee22c
  14. 24 Aug, 2009 1 commit
  15. 10 Aug, 2009 1 commit
  16. 24 Jul, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Add IDs for 51 new flash chips · 350a0c34
      Carl-Daniel Hailfinger authored
      
      AMIC A29400T
      AMIC A29400U
      AMIC A29800T
      AMIC A29800U
      AMIC A29L004T
      AMIC A29L004U
      AMIC A29L008T
      AMIC A29L008U
      AMIC A29L040
      Macronix MX29F004B
      Macronix MX29F004T
      Macronix MX29F022T
      Macronix MX29F080
      Macronix MX29F800B
      Macronix MX29F800T
      Macronix MX29LV081
      Spansion MBM29DL400BC
      Spansion MBM29DL400TC
      Spansion MBM29DL800BA
      Spansion MBM29DL800TA
      Spansion MBM29F002BC
      Spansion MBM29F002TC
      Spansion MBM29F040C
      Spansion MBM29F080A
      Spansion MBM29F200BC
      Spansion MBM29F200TC
      Spansion MBM29F800BA
      Spansion MBM29F800TA
      Spansion MBM29LV002BC
      Spansion MBM29LV002TC
      Spansion MBM29LV004BC
      Spansion MBM29LV004TC
      Spansion MBM29LV008BA
      Spansion MBM29LV008TA
      Spansion MBM29LV080A
      Spansion MBM29LV200BC
      Spansion MBM29LV200TC
      Spansion MBM29LV400BC
      Spansion MBM29LV400TC
      Spansion MBM29LV800BA
      Spansion MBM29LV800TA
      SST 49LF030A
      ST M29F080
      ST M29F200BB
      ST M29F200BT
      ST M29F400BB
      ST M29F800DB
      ST M29F800DT
      Winbond W39L020
      Winbond W39L040
      Winbond W49F020
      
      These still need to be added to flashchips.c, but if we ever encounter
      them in real life, the ID->name lookup will be a lot easier.
      
      Corresponding to flashrom svn r667.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      350a0c34
  17. 23 Jul, 2009 3 commits
  18. 11 Jul, 2009 1 commit
  19. 08 Jul, 2009 1 commit
  20. 03 Jul, 2009 1 commit
  21. 28 Jun, 2009 1 commit
  22. 22 Jun, 2009 4 commits
  23. 19 Jun, 2009 1 commit
  24. 15 Jun, 2009 2 commits
  25. 14 Jun, 2009 1 commit
  26. 12 Jun, 2009 2 commits
  27. 05 Jun, 2009 3 commits
  28. 03 Jun, 2009 1 commit