1. 25 Sep, 2012 1 commit
  2. 25 Aug, 2012 1 commit
  3. 22 Jul, 2012 1 commit
  4. 06 Jun, 2012 1 commit
  5. 14 May, 2012 1 commit
  6. 16 Feb, 2012 1 commit
    • Carl-Daniel Hailfinger's avatar
      Reenable forced read · b428e97c
      Carl-Daniel Hailfinger authored
      
      Forced read functionality was disabled when programmer registration was
      merged in r1475.
      
      We now support registering more than one controller at once for each bus
      type. This can happen e.g. if one SPI controller has an attached flash
      chip and one controller doesn't. In such a case we rely on the probe
      mechanism to find exactly one chip, and the probe mechanism will
      remember which controller/bus the flash chip is attached to. A forced
      read does not have the luxury of knowing which compatible controller to
      use, so this case is handled by always picking the first one. That may
      or may not be the correct one, but there is no way (yet) to specify
      which controller a flash chip is attached to.
      
      Corresponding to flashrom svn r1496.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
      b428e97c
  7. 11 Jan, 2012 1 commit
  8. 04 Jan, 2012 1 commit
  9. 25 Dec, 2011 1 commit
  10. 22 Dec, 2011 1 commit
  11. 20 Dec, 2011 1 commit
    • Carl-Daniel Hailfinger's avatar
      Have all programmer init functions register bus masters/programmers · c40cff7b
      Carl-Daniel Hailfinger authored
      All programmer types (Parallel, SPI, Opaque) now register themselves
      into a generic programmer list and probing is now programmer-centric
      instead of chip-centric.
      Registering multiple SPI/... masters at the same time is now possible
      without any problems. Handling multiple flash chips is still unchanged,
      but now we have the infrastructure to deal with "dual BIOS" and "one
      flash behind southbridge and one flash behind EC" sanely.
      
      A nice side effect is that this patch kills quite a few global variables
      and improves the situation for libflashrom.
      
      Hint for developers:
      struct {spi,par,opaque}_programmer now have a void *data pointer to
      store any additional programmer-specific data, e.g. hardware
      configuration info.
      
      Note:
      flashrom -f -c FOO -r forced_read.bin
      does not work anymore. We have to find an architecturally clean way to
      solve this.
      
      Corresponding to flashrom svn r1475.
      
      Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006...
      c40cff7b
  12. 14 Dec, 2011 1 commit
    • Carl-Daniel Hailfinger's avatar
      Use struct flashctx instead of struct flashchip for flash chip access · 63fd9026
      Carl-Daniel Hailfinger authored
      
      Struct flashchip is used only for the flashchips array and for
      operations which do not access hardware, e.g. printing a list of
      supported flash chips.
      
      struct flashctx (flash context) contains all data available in
      struct flashchip, but it also contains runtime information like
      mapping addresses. struct flashctx is expected to grow additional
      members over time, a prime candidate being programmer info.
      struct flashctx contains all of struct flashchip with identical
      member layout, but struct flashctx has additional members at the end.
      
      The separation between struct flashchip/flashctx shrinks the memory
      requirement of the big flashchips array and allows future extension
      of flashctx without having to worry about bloat.
      
      Corresponding to flashrom svn r1473.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarMichael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
      63fd9026
  13. 09 Nov, 2011 1 commit
  14. 11 Sep, 2011 1 commit
  15. 08 Sep, 2011 1 commit
  16. 20 Aug, 2011 1 commit
  17. 15 Aug, 2011 1 commit
  18. 28 Jul, 2011 1 commit
  19. 25 Jul, 2011 1 commit
  20. 19 Jul, 2011 1 commit
  21. 15 Jul, 2011 1 commit
  22. 14 Jun, 2011 1 commit
    • David Hendricks's avatar
      Use shutdown callback mechanism to shutdown programmers · 8bb2021d
      David Hendricks authored
      
      This patch attempts to resolve some programmer shutdown ordering issues
      by having the programmer init functions register shutdown callbacks explicitly
      wherever it makes most sense. Before, assumptions were made that could lead to
      the internal programmer's state changing before the external programmer could be
      shut down properly. Now, each programmer cleans up after itself and (hopefully)
      performs each operation in the correct order.
      
      As a side-effect, this patch gives us a better usage model for reverse
      operations such as rpci_* and rmmio_*. In the long-run, this should make
      reversing the initialization process easier to understand, less tedious, and
      less error-prone.
      
      In short, this patch does the following:
      - Registers a shutdown callback during initialization for each programmer.
      - Kills the .shutdown function pointer from programmer_entry struct. Also,
        make most shutdown functions static.
      - Adds a few minor clean-ups and corrections (e.g. missing physunmap() calls).
      
      TODO: Remove forward declaration of serprog_shutdown() (added to simplify diff)
      
      Corresponding to flashrom svn r1338.
      Signed-off-by: default avatarDavid Hendricks <dhendrix@google.com>
      Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      8bb2021d
  23. 07 May, 2011 1 commit
  24. 04 May, 2011 1 commit
  25. 24 Jan, 2011 1 commit
  26. 17 Jan, 2011 1 commit
  27. 06 Oct, 2010 2 commits
  28. 15 Sep, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Delay between probe and subsequent operations · 9ad4255b
      Carl-Daniel Hailfinger authored
      
      Some flash chips need time to exit ID mode, and while we take care of
      correct timing for the matching probe, subsequent probes may have
      totally different timing, and that can lead to garbage responses from
      the flash chip during the first accesses after the probe sequence is
      done.
      Delay 100 ms between the last probe and any subsequent operation.
      To ensure maximum correctness, we would have to reset the chip first in
      case the last probe function left the chip in an undefined (non-read)
      state. That will be possible once struct flashchip has a .reset
      function.
      
      This fixes unstable erase/read/write for some flahs chips on nic3com and
      possible other use cases as well.
      
      Thanks to Maciej Pijanka for reporting the issue and testing patches.
      
      Corresponding to flashrom svn r1172.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarMichael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
      9ad4255b
  29. 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
  30. 13 Jul, 2010 1 commit
  31. 03 Jul, 2010 1 commit
  32. 04 Jun, 2010 1 commit
    • Uwe Hermann's avatar
      Make the 'flashrom --help' output look a bit nicer · 2db77a03
      Uwe Hermann authored
      
      Only print "flashrom" as the program name unconditionally, not the full path
      and program name (e.g. "/home/foo/bar/baz/flashrom" or on Windows
      "C:\Foo\Bar\Whatever\flashrom.exe"). The path or exact executable name is
      not really useful to print here, if you managed to run --help you already
      know it, and it just makes the output look ugly.
      
      Also, add a missing newline to make the output look nicer.
      
      Finally, revert the "CONFIG_PRINT_WIKI ?= yes" change which accidentally
      slipped into r1029.
      
      Corresponding to flashrom svn r1030.
      Signed-off-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      2db77a03
  33. 31 May, 2010 1 commit
  34. 30 May, 2010 1 commit
  35. 22 May, 2010 1 commit
  36. 15 May, 2010 1 commit
  37. 28 Apr, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      One of the problems is that --force had multiple meanings · 27023768
      Carl-Daniel Hailfinger authored
      
      - Force chip read by faking probe success.
      - Force chip access even if the chip is bigger than max decode size for
        the flash bus.
      - Force erase even if erase is known bad.
      - Force write even if write is known bad.
      - Force writing even if cbtable tells us that this is the wrong image
        for this board.
      
      This patch cleans up --force usage:
      - Remove any suggestions to use --force for probe/read from flashrom
        output.
      - Don't talk about "success" or "Found chip" if the chip is forced.
      - Add a new internal programmer parameter boardmismatch=force. This
        overrides any mismatch detection from cbtable/image comparisons.
      - Add a new internal programmer parameter laptop=force_I_want_a_brick.
      - Adjust the documentation for --force.
      - Clean up the man page a bit whereever it talks about --force or
        laptops.
      
      Additional changes in this patch:
      - Add warnings about laptops to the documentation.
      - Abort if a laptop is detected. Can be overridden with the programmer
      parameter mentioned above.
      - Add "Portable" to the list of DMI strings indicating laptops.
      - Check if a chip specified with -c is known to flashrom.
      - Programmer parameter reliability and consistency fixes.
      - More paranoid self-checks.
      - Improve documentation.
      
      Corresponding to flashrom svn r996.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarMichael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
      27023768
  38. 12 Jan, 2010 1 commit
  39. 07 Jan, 2010 1 commit