Skip to content

GitLab

Switch branch/tag
  1. 13 Aug, 2013 2 commits
  3. 12 Aug, 2013 1 commit
    • Stefan Tauner's avatar
      Fix verification operation · c4f44df5
      Stefan Tauner authored 
      
I broke this in r1702 where I enabled avoidance of the verification step if
we did not modify anything in the erase/write step. The problem is that
all_skipped is initialized to true and hence it would only ever verify if
there have been changes noted in the erase/write step. This obviously
breaks the verification operation (-v/--verify) because there we never
enter the erase/write loop.

The better alternative would be to enable (the implicit) verification
in the write loop and not in cli_classic.c. This would require a bigger
change due to the existance of dont_verify_it. Eventually this is the
right thing to do but not so shortly before a release.

Corresponding to flashrom svn r1707.
Signed-off-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      c4f44df5
  5. 08 Aug, 2013 1 commit
  7. 30 Jul, 2013 1 commit
  9. 25 Jul, 2013 3 commits
  11. 17 Jul, 2013 2 commits
  13. 15 Jul, 2013 1 commit
    • Stefan Tauner's avatar
      Differentiate ultimate error messages depending on programmer used · 136388ff
      Stefan Tauner authored 
      
With every newly supported programmer the information regarding reboots
on failures becomes more ridiculous. With this patch it is only shown when
the internal programmer module was selected.

Example outputs for external programmers:
1) non-fatal:
[…]
Reading current flash chip contents... done. FAILED at 0x00000000! Expected=0xff, Found=0x28, failed byte count from 0x00000000-0x0001ffff: 0x1fde7
ERASE FAILED!
FAILED!
Uh oh. Erase/write failed. Checking if anything changed.
Good. It seems nothing was changed.
Writing to the flash chip apparently didn't do anything.
Please check the connections (especially those to write protection pins) between
the programmer and the flash chip. If you think the error is caused by flashrom
please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom@flashrom.org, thanks!

2) fatal:
[…]
Verifying flash... FAILED at 0x00000000! Expected=0x0f, Found=0xff, failed byte count from 0x00000000-0x0001ffff: 0x1fde6
Your flash chip is in an unknown state.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom@flashrom.org, thanks!

Corresponding to flashrom svn r1699.
Signed-off-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: default avatarDavid Hendricks <dhendrix@google.com>
Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      136388ff
  15. 13 Jul, 2013 4 commits
  17. 11 Jul, 2013 1 commit
    • Stefan Tauner's avatar
      print_wiki: Fixes, explanation re · 1c356bb6
      Stefan Tauner authored 
      
Flash chips, links to footnotes.

 - Escape mainboard notes in the wiki output with <nowiki> (this became
necessary because MediaWiki started to convert <mark@zl2tod.net> to
<mark>). - Add explanations at the top of the flash chip table in the
wiki. - Add links to the footnotes of mainboards and laptops similarly
to what MediaWiki does: link from the reference to the footnote and
vice versa too. Also, check for truncations of the footnotes due to the
limited buffer. - Fix a typo introduced in r1555.

Corresponding to flashrom svn r1694.
Signed-off-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
      1c356bb6
  19. 28 Jun, 2013 13 commits
  21. 23 Jun, 2013 1 commit
  23. 20 Jun, 2013 1 commit
    • Stefan Tauner's avatar
      Fix unlocking function for most Atmel AT2[56]D* chips · cecb2c56
      Stefan Tauner authored 
      I broke unlocking them correctly in r1635 while refactoring (NB: the
commit log including the overly selfconfident statement about the
"bug in spi_disable_blockprotect_at25df()").

Affected chips have per sector protection bits and the write protection bits
in the status register do indicate if none, some or all sectors are protected.
It is possible to globally (un)lock all sectors at once but in a way that was
not anticipated when refactoring the spi25 unlocking functions into
spi_disable_blockprotect_generic(). To globally unprotect not only the
protection bits (2 and 3) have 0 to be written to them but also bits 4 and 5
which normally would not be touched by spi_disable_blockprotect_generic().
Some of the chips also support a permanent lockdown with fuses which we
do not handle yet.

To fix this without copying the whole method I introduce another mask
parameter to spi_disable_blockprotect_generic() namely unprotect_mask.
See verbose comments inline...
      cecb2c56
  25. 16 Jun, 2013 1 commit
  27. 09 Jun, 2013 1 commit
  29. 01 Jun, 2013 1 commit
  31. 23 May, 2013 1 commit
  33. 03 May, 2013 1 commit
  35. 01 May, 2013 1 commit
  37. 19 Apr, 2013 2 commits
  39. 13 Apr, 2013 1 commit

Powered by Integricloud