1. 28 Nov, 2009 2 commits
  2. 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) ...
      1c296ca8
  3. 26 Nov, 2009 3 commits
    • Carl-Daniel Hailfinger's avatar
      Add support for Intel 3400 series / 5 series chipset · 797a8346
      Carl-Daniel Hailfinger authored
      Found in Intel document 322170 (Intel 5 Series Chipset and Intel 3400
      Series Chipset Specification Update).
      According to http://pciids.sourceforge.net/
      
       we probably should match all
      IDs from 0x3b00-0x3b1f, but so far I didn't find an Intel doc saying the
      same.
      If anybody has contacts at Intel and can check, I'd be happy to add the
      rest of the IDs.
      
      Corresponding to flashrom svn r784.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarSean Nelson <audiohacked@gmail.com>
      797a8346
    • Michael Karcher's avatar
      Refine support for the JEDEC Software Data Protection · 972cec28
      Michael Karcher authored
      This patch removes the extremely dangerous unprotect_jedec function
      which is not used at all within flashrom code, and renames the
      misleadingly named protect_jedec function to start_program_jedec.
      
      Calls to protect_jedec after flashing are removed, because a) on LPC
      chips, the command sent by protoct_jedec is not even in the datasheet
      and b) on parallel chips, the block write command issued before already
      contained the software protection sequence, so software protection is
      definitely enabled.
      
      This patch also removes two clones of protect_jedec
      
      Background: JEDEC Software Data Protection started as an optional
      feature, which was disabled on the first single-voltage-flash chips.
      The software data protection is the need to prefix a write with a magic
      "write enable" command, while without write protection every write
      access into the chip's address space modifies flash content. This magic
      write enable command also tells the flash chip that the programmer
      ...
      972cec28
    • Zheng Bao's avatar
      Add entries of W25x32 and W25x64 · 1db2b759
      Zheng Bao authored
      
      The model_ids are already in the header.
      
      W25x32 has been successfully probed. W25x64 is not available, the entry
      is based on the datasheet.
      
      Corresponding to flashrom svn r782.
      Signed-off-by: default avatarZheng Bao <zheng.bao@amd.com>
      Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      1db2b759
  4. 25 Nov, 2009 5 commits
  5. 24 Nov, 2009 5 commits
  6. 23 Nov, 2009 2 commits
  7. 22 Nov, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      ft2232_spi: add some error handling · a2441cef
      Carl-Daniel Hailfinger authored
      
      Pretty much everybody who used the FT2232 SPI driver had problems with
      incorrect reads from time to time. One reason was that the hardware is
      pretty timing sensitive even for reads.
      
      The other reason was that the code silently ignored errors. This patch
      doesn't add any error recovery, but it will emit error messages if
      FT2232 communication goes wrong. That allows us to track down errors
      without investing hours in driver debugging.
      
      Thanks to Jeremy Buseman <naviathan@gmail.com> for testing. He found out
      that certain libftdi/libusb/kernel/hardware combinations drop some bytes
      without returning any error codes.
      
      Corresponding to flashrom svn r769.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarPaul Fox <pgf@laptop.org>
      a2441cef
  8. 21 Nov, 2009 1 commit
  9. 20 Nov, 2009 1 commit
  10. 17 Nov, 2009 1 commit
  11. 16 Nov, 2009 4 commits
  12. 15 Nov, 2009 3 commits
  13. 14 Nov, 2009 2 commits
  14. 06 Nov, 2009 1 commit
  15. 31 Oct, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Add infrastructure to check the maximum supported flash size of chipsets and mainboards · 115d390f
      Carl-Daniel Hailfinger authored
      
      The rationale is to warn users when they, for example, try to flash
      a 512KB parallel flash chip but their chipset only supports 256KB,
      or they try to flash 512KB and the chipset _does_ theoretically
      support 512KB but their special board doesn't wire all address lines
      and thus supports only 256 KB ROM chips at maximum.
      
      This has cost Uwe hours of debugging on some board already, until he
      figured out what was going on. We should try warn our users where
      possible about this.
      
      The chipset and the chip may have more than one bus in common (e.g.
      SB600 and Pm49* can both speak LPC+FWH) and on SB600/SB7x0/SB8x0 there
      are different limits for LPC and FWH. The only way to tell the user
      about the exact circumstances is to spew error messages per bus.
      
      The code will issue a warning during probe (which does fail for some
      chips if the size is too big) and abort before the first real
      read/write/erase action. If no action is specified, the warning is
      printed anyway.
      That way, a user can find out why probe might not have worked, and will
      be stopped before he/she gets incorrect results.
      
      Add a bitcount function to the infrastructure.
      
      Corresponding to flashrom svn r755.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      115d390f
  16. 30 Oct, 2009 1 commit
  17. 22 Oct, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      ichspi: remove obnoxious debug message · 0709a782
      Carl-Daniel Hailfinger authored
      
      Since we don't have any debug level printing infrastructure yet, I
      propose to kill the obnoxious debug message in ichspi.c which was added
      to check for correct PREOP handling.
      
      We know the code works fine (after getting a few reports over 100 MB
      long) and there's no point in keeping it around anymore. If there is any
      desire, we can reinstate it as print_spew or whatever once the debug
      level infrastructure is merged, but at that point we probably just are
      happy that the debug output isn't there anymore.
      
      Corresponding to flashrom svn r753.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarLuc Verhaegen <libv@skynet.be>
      0709a782
  18. 21 Oct, 2009 1 commit
  19. 19 Oct, 2009 1 commit
  20. 06 Oct, 2009 3 commits