1. 04 Jun, 2010 1 commit
  2. 03 Jun, 2010 1 commit
  3. 01 Jun, 2010 1 commit
  4. 31 May, 2010 1 commit
  5. 30 May, 2010 1 commit
  6. 28 May, 2010 1 commit
  7. 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
  8. 21 May, 2010 1 commit
  9. 15 May, 2010 1 commit
  10. 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
  11. 03 Apr, 2010 1 commit
  12. 22 Mar, 2010 1 commit
  13. 08 Mar, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Write granularity is chip specific · e8e369fc
      Carl-Daniel Hailfinger authored
      
      The following write granularities exist according to my datasheet
      survey: - 1 bit. Each bit can be cleared individually. - 1 byte. A byte
      can be written once. Further writes to an already written byte cause
      the contents to be either undefined or to stay unchanged. - 128 bytes.
      If less than 128 bytes are written, the rest will be erased. Each write
      to a 128-byte region will trigger an automatic erase before anything is
      written. Very uncommon behaviour. - 256 bytes. If less than 256 bytes
      are written, the contents of the unwritten bytes are undefined.
      
      Note that chips with default 256-byte writes, which keep the original
      contents for unwritten bytes, have a granularity of 1 byte.
      
      Handle 1-bit, 1-byte and 256-byte write granularity.
      
      Corresponding to flashrom svn r927.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarSean Nelson <audiohacked@gmail.com>
      Acked-by: default avatarDavid Hendricks <dhendrix@google.com>
      e8e369fc
  14. 28 Feb, 2010 1 commit
  15. 26 Feb, 2010 2 commits
  16. 24 Feb, 2010 1 commit
  17. 21 Feb, 2010 1 commit
  18. 19 Feb, 2010 1 commit
  19. 14 Feb, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Allow the registration of functions to be called at programmer shutdown · cc389fc6
      Carl-Daniel Hailfinger authored
      
      Some programmers want to run certain functions during programmer
      shutdown, but the function choice depends on the code path taken
      during programmer init. Rather than rebuilding the whole init logic in
      the shutdown function, it is now possible to register functions for
      execution on programmer shutdown. The behaviour is similar to atexit(),
      but the registered functions will be run on programmer shutdown instead
      of on exit and the functions will be called with a void * argument
      that is specified on registration. Registered functions must have
      the prototype void function(void *); and will be executed in reverse
      registration order directly before calling the programmer-specific
      shutdown() function. It is recommended to have shutdown() only disable
      programmer/hardware access and leave all code path sensitive shutdown to
      functions registered with register_shutdown().
      
      The most prominent use case is resetting the EC after flashing on
      laptops.
      
      Note: There are quite a few code paths in flashrom which proceed to
      terminate flashrom without any programmer shutdown. Those code paths
      will not get the benefit of register_shutdown() and they should be
      changed wherever possible.
      
      Corresponding to flashrom svn r904.
      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>
      cc389fc6
  20. 11 Feb, 2010 1 commit
  21. 02 Feb, 2010 1 commit
  22. 28 Jan, 2010 1 commit
    • Sean Nelson's avatar
      Complete the addition of Feature Bits for all Jedec based chips · 35727f76
      Sean Nelson authored
      
      Add FEATURE_SHORT_RESET, FEATURE_LONG_RESET, and FEATURE_EITHER_RESET
      rewrite jedec functions to use getaddrmask
      
      convert write_49f002 to write_jedec_1
      convert write_w39v040c to write_jedec_1
      convert probe_w39v040c to probe_jedec
      convert write_49lf040 to write_jedec_1
      convert write_pm29f002 to write_jedec
      convert write_29f040b to write_jedec_1
      convert probe_29f040b to probe_jedec
      convert erase_chip_29f040b to erase_chip_block_jedec
      convert erase_sector_29f040b to erase_sector_jedec
      convert write_m29f002b to write_jedec
      convert write_m29f002t to write_jedec
      convert *_29f002 to *_jedec
      
      decouple unused files from Makefile:
      am29f040b.c
      en29f002a.c
      m29f002.c
      mx29f002.c
      pm29f002.c
      sst49lf040.c
      w39v040c.c
      w49f002u.c
      
      Corresponding to flashrom svn r886.
      Signed-off-by: default avatarSean Nelson <audiohacked@gmail.com>
      Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarAnders Juel Jensen <andersjjensen@gmail.com>
      35727f76
  23. 20 Jan, 2010 2 commits
    • Luc Verhaegen's avatar
      Boards: Add max_rom_decode_parallel entry to board enable table · 93938c32
      Luc Verhaegen authored
      
      This is a quick fix for board specific parallel addressing limits.
      
      Corresponding to flashrom svn r875.
      Signed-off-by: default avatarLuc Verhaegen <libv@skynet.be>
      Acked-by: default avatarSean Nelson <audiohacked@gmail.com>
      93938c32
    • 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
  24. 19 Jan, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Dediprog SF100 support · d38fac8c
      Carl-Daniel Hailfinger authored
      
      Reverse engineered from USB logs. I never touched that programmer nor
      did I ever see the associated software.
      Disabled by default until it is complete. The driver needs to be hooked
      up to the SPI core before it will do anything besides init and
      diagnostics.
      
      I successfully reverse engineered all commands, but some are still
      somewhat magic.
      Logs from "flashrom -p dediprog -V" are appreciated.
      
      Probe and read should work, erase/write is expected to explode.
      The programmer will set voltage to 0 on exit.
      
      Thanks a lot to Stefan Reinauer and Patrick Georgi for providing USB
      logs and for testing the result.
      
      Corresponding to flashrom svn r870.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarStefan Reinauer <stepan@coresystems.de>
      d38fac8c
  25. 12 Jan, 2010 1 commit
  26. 09 Jan, 2010 2 commits
  27. 07 Jan, 2010 2 commits
  28. 06 Jan, 2010 4 commits
  29. 04 Jan, 2010 1 commit
  30. 24 Dec, 2009 2 commits
  31. 22 Dec, 2009 2 commits