1. 26 Sep, 2010 1 commit
  2. 08 Aug, 2010 1 commit
  3. 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
  4. 03 Jul, 2010 1 commit
  5. 23 Jun, 2010 1 commit
  6. 07 May, 2010 1 commit
  7. 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
  8. 24 Mar, 2010 1 commit
  9. 14 Mar, 2010 1 commit
  10. 13 Mar, 2010 1 commit
  11. 26 Feb, 2010 2 commits
  12. 24 Feb, 2010 1 commit
  13. 12 Feb, 2010 1 commit
  14. 27 Jan, 2010 1 commit
  15. 20 Jan, 2010 1 commit
    • Michael Karcher's avatar
      Matching board via DMI · 6701ee83
      Michael Karcher authored
      
      If a board is not uniquely identifiable by PCI device/subsystem IDs, a
      string can be specified to be looked for (case-sensitive, substring or
      anchored) for now in one of the following DMI items in addition to matching
      the PCI IDs:
       - System Manufacturer
       - System Product Name
       - System Version
       - Baseboard Manufacturer
       - Baseboard Product Name
       - Baseboard Version
      
      Strings are anchored re-like (^ at the beginning, $ at the end), but
      there are no plans to support full regular expressions and matched to any
      of the mentioned fields.
      
      The match is only made if DMI info is available and the string matches.
      If no DMI info is available and the PCI IDs match, a warning is printed
      as the board can not be autodetected.
      
      It's still open to discussion whether we add an DMI override switch to
      specify a string that will definitely match, and whether this switch is
      only used if no DMI is available or whether it overrides or augments DMI
      data.
      
      DMI data is currently read using dmidecode. This tool is available for
      all major platforms except MacOS X. I heard that there also is a MacOS X
      version of dmidecode, but didn't investigate that.
      
      Corresponding to flashrom svn r874.
      Signed-off-by: default avatarMichael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
      Acked-by: default avatarLuc Verhaegen <libv@skynet.be>
      Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      6701ee83