Skip to content

GitLab

Switch branch/tag
  1. 13 Jul, 2013 2 commits
  3. 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
  5. 28 Jun, 2013 13 commits
  7. 23 Jun, 2013 1 commit
  9. 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 for details.

Also, prettyprint the status register after trying to disable the block
protection fails.

Corresponding to flashrom svn r1679.
Signed-off-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Tested-by: default avatarChi Zhang <zhangchi866@gmail.com>
Acked-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
      cecb2c56
  11. 16 Jun, 2013 1 commit
  13. 09 Jun, 2013 1 commit
  15. 01 Jun, 2013 1 commit
  17. 23 May, 2013 1 commit
  19. 03 May, 2013 1 commit
  21. 01 May, 2013 1 commit
  23. 19 Apr, 2013 2 commits
  25. 13 Apr, 2013 1 commit
  27. 07 Apr, 2013 1 commit
  29. 05 Apr, 2013 1 commit
  31. 01 Apr, 2013 8 commits
  33. 27 Mar, 2013 1 commit
  35. 16 Mar, 2013 1 commit
    • Stefan Tauner's avatar
      Fix evil twins of Macronix MX25L1605, MX25L3205, MX25L6405 · 226037da
      Stefan Tauner authored 
      Similarly to the patch in r1647 this one updates the chips identified as above
with references to and data about their respective twins. Unlike previously this
one deals with the more evil details.

Helge Wagner from GE discovered some problems with chips sharing IDs
and proposed a patch to tackle (some of) them, see:
http://patchwork.coreboot.org/patch/3709/
That patch was bitrotting in our mailboxes for a long time and it is still not
ready for merge, but we increasingly get reports about problems (e.g.
http://paste.flashrom.org/view.php?id=1525

) regarding these chips and
hence must act to ensure users' safety.

This patch splits the chip definitions of evil twins into separate ones which
correctly declare the respective attributes (the main problems are the erase
block sizes for the 0x20 opcode and hence my changes combine different
chips with partly different attributes apart from their names as long as the
erasers layout it the same). This forces the user to select the (right) chip
definition with the -c/--chip parameter and hence will break a number of
previously perfectly working environments.

0x2015 is used by and split to
 - MX25L1605 (64kB sectors in 0x20 erases)
 - MX25L1605A/MX25L1606E (4kB in 0x20 erases and an additional 0x52 opcode with 64kB blocks)
 - MX25L1605D/MX25L1608D (4k sectors in 0x20 erases)

0x2016 is used by and split to
 - MX25L3205/MX25L3205A (64kB 0x20)
 - MX25L3205D/MX25L3208D (4kB 0x20)
 - MX25L3206E (4k 0x20, 64k 0x52)

0x2017 is used by and split to
 - MX25L6405/MX25L6405D (64k 0x20)
 - MX25L6406E/MX25L6436E (4k 0x20)
 - MX25L6445E (4k 0x20, 64k 0x52)

Bonus: add some minor details to MX25L1635D, MX25L1635E, MX25L3235D,
MX25L12805D.

Tested with MX25L3206E, MX25L64036E.

Corresponding to flashrom svn r1657.
Signed-off-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
      226037da
  37. 15 Mar, 2013 1 commit

Powered by Integricloud