1. 16 May, 2014 2 commits
  2. 15 Sep, 2013 1 commit
  3. 14 Sep, 2013 1 commit
  4. 12 Sep, 2013 1 commit
  5. 14 Aug, 2013 1 commit
  6. 08 Aug, 2013 1 commit
  7. 25 Jul, 2013 1 commit
  8. 16 Jun, 2013 1 commit
  9. 20 Jul, 2012 1 commit
  10. 15 Jun, 2012 1 commit
  11. 18 Dec, 2011 1 commit
  12. 26 Aug, 2011 1 commit
  13. 16 Aug, 2011 1 commit
  14. 11 May, 2011 2 commits
  15. 17 Jan, 2011 1 commit
  16. 15 Sep, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Detect embedded EC (IMC) in AMD's SBs · 39446e34
      Carl-Daniel Hailfinger authored
      
      AMD SB700 and later have an integrated microcontroller (IMC) which runs
      from shared flash.
      
      The IMC will happily issue reads while we write, issue writes while we
      read, and generally cause lots of havoc due to the concurrent accesses
      it performs while flashrom is running. A failing or corrupted read can
      be detected since r1145, and the worst case is that the read aborts and
      the user has to retry. A failing write is much more serious. It can
      be detected since r1145, but if the SPI interface locks up, we can't
      continue writing nor can we read the current chip contents.
      
      If the IMC is inactive, there is no reason to worry. If the IMC is
      active, flashrom will refuse to erase/write the chip with this patch.
      
      The correct fix would be to stop the IMC during flashing, but apparently
      the relevant registers are undocumented, so we take the safe route for
      now until someone from AMD can give us more info.
      
      Corresponding to flashrom svn r1173.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Tested-by: default avatarMatthias Kretz <kretz@kde.org>
      Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      39446e34
  17. 18 Aug, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Add paranoid checks to sb600spi driver · eb0e7fc4
      Carl-Daniel Hailfinger authored
      
      Add paranoid checks for correct values in essential registers in the SB600/SB700/... SPI driver. If something else changes the values we
      wrote, we will see severe read/write corruption.
      sb600spi will now abort the access and return an error if it detects
      this sort of corruption.
      
      Note: This corruption can be caused by a few different events:
      - IPMI/BMC/IMC accesses flash
      - Other software accesses flash
      The nature of flash access (read/write/ID/...) is irrelevant. Each such
      access will cause corruption for all other accesses happening at the
      same time.
      
      Thanks to Matthias Kretz for testing this patch.
      
      Corresponding to flashrom svn r1145.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarMatthias Kretz <kretz@kde.org>
      eb0e7fc4
  18. 27 Jul, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Split off programmer.h from flash.h · 5b997c3e
      Carl-Daniel Hailfinger authored
      
      Programmer specific functions are of absolutely no interest to any file
      except those dealing with programmer specific actions (special SPI
      commands and the generic core).
      
      The new header structure is as follows (and yes, improvements are
      possible):
      flashchips.h  flash chip IDs
      chipdrivers.h  chip-specific read/write/... functions
      flash.h  common header for all stuff that doesn't fit elsewhere
      hwaccess.h hardware access functions
      programmer.h  programmer specific functions
      coreboot_tables.h  header from coreboot, internal programmer only
      spi.h SPI command definitions
      
      Corresponding to flashrom svn r1112.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      5b997c3e
  19. 22 Jul, 2010 1 commit
  20. 14 Jul, 2010 2 commits
  21. 30 May, 2010 1 commit
  22. 26 May, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Handle the following architectures in generic flashrom code · cceafa2a
      Carl-Daniel Hailfinger authored
      
      - x86/x86_64 (little endian)
      - PowerPC (big endian)
      - MIPS (big+little endian)
      
      No changes to programmer specific code. This means any drivers with MMIO
      access will _not_ suddenly start working on big endian systems, but with
      this patch everything is in place to fix them.
      
      Compilation should work on all architectures listed above for all
      drivers except nic3com and nicrealtek which require PCI Port IO which is
      x86-only for now.
      
      To compile without nic3com and nicrealtek, run
      make distclean
      make CONFIG_NIC3COM=no CONFIG_NICREALTEK=no
      
      Thanks to Misha Manulis for testing early versions of this patch on
      PowerPC (big endian) with the satasii programmer.
      Thanks to Segher Boessenkool for design review and for helping out with
      compiler tricks and pointing out that we need eieio on PowerPC.
      Thanks to Vladimir Serbinenko for compile testing on MIPS (little
      endian) and PowerPC (big endian) and for runtime testing on MIPS (little
      endian).
      Thanks to David Daney for compile testing on MIPS (big endian).
      Thanks to Uwe Hermann for compile and runtime testing on x86_64.
      
      DO NOT RUN flashrom ON NON-X86 AFTER APPLYING THIS PATCH!
      This patch only provides the infrastructure, but does not convert any
      drivers, so flashrom will compile, but it won't do the right thing on
      non-x86 platforms.
      
      Corresponding to flashrom svn r1013.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarMisha Manulis <misha@manulis.com>
      Acked-by: default avatarVladimir 'phcoder/φ-coder' Serbinenko <phcoder@gmail.com>
      Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      Acked-by: default avatarSegher Boessenkool <segher@kernel.crashing.org>
      cceafa2a
  23. 21 May, 2010 1 commit
  24. 26 Feb, 2010 1 commit
  25. 10 Jan, 2010 1 commit
  26. 07 Jan, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Allow one to disable programmer debug messages at compile time · 5609fa75
      Carl-Daniel Hailfinger authored
      Programmer debug messages during programmer init/shutdown are useful
      because they print hardware settings and desired configuration.
      
      They help in getting a quick overview of hardware and software state on
      startup and shutdown.
      
      Programmer debug messages during flash chip access are mostly a
      distraction in logs and should only be enabled if someone is having
      problems which are suspected to stem from a programmer hardware or
      programmer software bug. Disable those messages by default, they can be
      reenabled by #define COMM_DEBUG in the affected programmer file.
      
      An added benefit is a tremendous size reduction in verbose
      probe/read/write/erase logs because only flash chip driver messages
      remain. In some cases, logs will shrink from 65 MB to 10 kB or less.
      
      The right(tm) fix would be two different debug levels (DEBUG and SPEW)
      and the ability to differentiate between programmer debug messages and
      flash chip debug messages. Until the design for the ...
      5609fa75
  27. 01 Oct, 2009 1 commit
  28. 16 Sep, 2009 1 commit
  29. 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 b...
      f38431a5
  30. 10 Aug, 2009 1 commit
  31. 09 Aug, 2009 1 commit
  32. 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
  33. 14 Jul, 2009 1 commit
  34. 12 Jul, 2009 1 commit
  35. 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
  36. 23 Jun, 2009 1 commit
  37. 16 Jun, 2009 1 commit