1. 30 May, 2010 5 commits
  2. 28 May, 2010 2 commits
  3. 26 May, 2010 3 commits
  4. 25 May, 2010 1 commit
  5. 24 May, 2010 3 commits
  6. 22 May, 2010 3 commits
  7. 21 May, 2010 4 commits
  8. 19 May, 2010 1 commit
  9. 17 May, 2010 1 commit
  10. 15 May, 2010 1 commit
  11. 07 May, 2010 1 commit
  12. 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
  13. 25 Apr, 2010 1 commit
    • Rudolf Marek's avatar
      Fix the DOS port · 837d8107
      Rudolf Marek authored
      
      Now the DS selector limit is set to 4GB and all mmio accesses goes
      through DS, the 1:1 mapping is fixed so the _DS base is taken onto
      account. Plus is that the hwaccess.c needs no change and memcpy etc can
      be used on mmaped space.
      
      Corresponding to flashrom svn r995.
      
      Signed-off-by: Rudolf Marek <r.marek@assembler.cz> 
      Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      837d8107
  14. 20 Apr, 2010 1 commit
  15. 11 Apr, 2010 1 commit
  16. 09 Apr, 2010 1 commit
  17. 03 Apr, 2010 1 commit
  18. 31 Mar, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Refine and fix the delay loop calculation · 253101e6
      Carl-Daniel Hailfinger authored
      
      The current delay loop calculation is still from revision 1 of flashrom,
      and since then it had a logic bug which caused all delays to be twice as
      long as intended.
      
      Fix the delay duration.
      
      Protect against delay loop overflows.
      
      Detect a non-working delay loop.
      
      Change the delay loop itself to ensure clever compiler optimizers won't
      eliminate it (as happens with clang/llvm in the current code). Some
      people suggested machine-specific asm, but the empty asm statement with
      the loop counter as register/memory input has the benefit of being
      perfectly cross-platform and working in gcc and clang.
      
      If time goes backwards (catastrophical NTP time difference, manual
      time change), timing measurements were shot because the new-old time
      subtraction yielded negative numbers which weren't handled correctly
      because the variable is unsigned. Work around that issue (a fix is
      mathematically impossible).
      
      If time goes forward too fast, pick the biggest possible timing
      measurement with a guaranteed overflow avoidance for all timing
      calculations.
      
      Check four times if the calculated timing is at most 10% too fast. This
      addresses OS scheduler interactions, e.g. being scheduled out during
      measurement which inflates measurements.
      
      If the timing looks like garbage, recalculate the timer values up to
      four times before giving up.
      
      Avoid division by zero in rare cases where timing measurements for a 250
      ms delay returned 0 us elapsed.
      
      Corresponding to flashrom svn r990.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarMaciej Pijanka <maciej.pijanka@gmail.com>
      253101e6
  19. 30 Mar, 2010 1 commit
  20. 27 Mar, 2010 3 commits
  21. 25 Mar, 2010 3 commits
  22. 24 Mar, 2010 1 commit