1. 14 Jul, 2010 1 commit
  2. 20 Jun, 2010 3 commits
  3. 31 May, 2010 1 commit
  4. 28 May, 2010 1 commit
  5. 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
  6. 21 May, 2010 1 commit
  7. 24 Mar, 2010 1 commit
  8. 26 Feb, 2010 1 commit
  9. 12 Feb, 2010 1 commit
  10. 22 Jan, 2010 1 commit
  11. 19 Jan, 2010 2 commits
  12. 12 Jan, 2010 1 commit
  13. 22 Dec, 2009 1 commit
  14. 13 Dec, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Internal (onboard) programming was the only feature which could not be disabled · 66ef4e5f
      Carl-Daniel Hailfinger authored
      Make various pieces of code conditional on support for internal
      programming. Code shared between PCI device programmers and onboard
      programming is now conditional as well.
      
      It is now possible to build only with dummy support:
      make CONFIG_INTERNAL=no CONFIG_NIC3COM=no CONFIG_SATASII=no
      CONFIG_DRKAISER=no CONFIG_SERPROG=no CONFIG_FT2232SPI=no
      
      This allows building for a specific use case only, and it also
      facilitates porting to a new architecture because it is possible to
      focus on highlevel code only.
      
      Note: Either internal or dummy programmer needs to be compiled in due to
      the current behaviour of always picking a default programmer if -p is
      not specified. Picking an arbitrary external programmer as default  
      wouldn't make sense.
      
      Build and runtime tested in all 1024 possible build combinations. The
      only failures are by design as mentioned above.
      
      Corresponding to flashrom svn r797.
      
      Signed-off-by: Carl-Daniel Hailfinger <c-d.h...
      66ef4e5f
  15. 24 Nov, 2009 2 commits
  16. 20 Nov, 2009 1 commit
  17. 16 Nov, 2009 1 commit
  18. 01 Oct, 2009 1 commit
  19. 18 Sep, 2009 1 commit
  20. 16 Sep, 2009 1 commit
  21. 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
  22. 02 Sep, 2009 1 commit
  23. 19 Aug, 2009 1 commit
  24. 10 Aug, 2009 1 commit
  25. 03 Aug, 2009 1 commit
  26. 23 Jul, 2009 2 commits
    • 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
    • Carl-Daniel Hailfinger's avatar
      Verbose probe output is split across multiple lines for some probe functions · 414bd320
      Carl-Daniel Hailfinger authored
      
      This makes visual inspection and grepping a lot harder than necessary.
      Remove line breaks where appropriate. Some error messages should end up
      on stderr instead of just being displayed in verbose mode.
      
      Thanks to Maciej Pijanka for testing.
      
      Corresponding to flashrom svn r660.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarStefan Reinauer <stepan@coresystems.de>
      414bd320
  27. 22 Jul, 2009 2 commits
  28. 12 Jul, 2009 1 commit
  29. 11 Jul, 2009 2 commits
  30. 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
  31. 24 Jun, 2009 1 commit
  32. 16 Jun, 2009 2 commits