1. 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
  2. 23 Jun, 2009 1 commit
  3. 16 Jun, 2009 1 commit
  4. 15 Jun, 2009 1 commit
  5. 13 Jun, 2009 1 commit
  6. 31 May, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Add bus type annotation to struct flashchips · 1dfe0ff1
      Carl-Daniel Hailfinger authored
      
      Right now, the annotation only differentiates between SPI and non-SPI.
      Anyone who knows more about a specific flash chip should feel free to
      update it.
      
      The existing flashbus variable was abused to denote the SPI controller
      type. Use an aptly named variable for that purpose.
      
      Once this patch is merged, the chipset/programmer init functions can set
      supported flash chip types and flashrom can automatically select only
      matching probe/read/erase/write functions. A side benefit of that will
      be the elimination of the Winbond W29EE011 vs. AMIC A49LF040A conflict.
      
      Corresponding to flashrom svn r556.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      1dfe0ff1
  7. 17 May, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Use accessor functions for MMIO · 78185dcb
      Carl-Daniel Hailfinger authored
      
      Some MMIO accesses used volatile, others didn't (and risked
      non-execution of side effects) and even with volatile, some accesses
      looked dubious.
      
      Since the MMIO accessor functions and the onboard flash accessor
      functions are functionally identical (but have different signatures),
      make the flash accessors wrappers for the MMIO accessors.
      
      For some of the conversions, I used Coccinelle. Semantic patch follows:
      
      @@ typedef uint8_t; expression a; volatile uint8_t *b; @@ - b[a] + *(b
      + a) @@ expression a; volatile uint8_t *b; @@ - *(b) |= (a); + *(b) =
      *(b) | (a); @@ expression a; volatile uint8_t *b; @@ - *(b) = (a); +
      mmio_writeb(a, b); @@ volatile uint8_t *b; @@ - *(b) + mmio_readb(b) @@
      type T; T b; @@ ( mmio_readb | mmio_writeb ) (..., - (T) - (b) + b )
      
      Corresponding to flashrom svn r524.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      
      Uwe tested read, write, erase with this patch on a random board to make
      sure nothing breaks.
      Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      78185dcb
  8. 16 May, 2009 1 commit
  9. 09 May, 2009 2 commits
  10. 13 Apr, 2009 1 commit
  11. 29 Nov, 2008 1 commit
  12. 28 Nov, 2008 1 commit