Skip to content

GitLab

Switch branch/tag
  1. 28 Jun, 2013 7 commits
  3. 23 Jun, 2013 1 commit
  5. 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
  7. 16 Jun, 2013 1 commit
  9. 09 Jun, 2013 1 commit
  11. 01 Jun, 2013 1 commit
  13. 23 May, 2013 1 commit
  15. 03 May, 2013 1 commit
  17. 01 May, 2013 1 commit
  19. 19 Apr, 2013 2 commits
  21. 13 Apr, 2013 1 commit
  23. 07 Apr, 2013 1 commit
  25. 05 Apr, 2013 1 commit
  27. 01 Apr, 2013 8 commits
  29. 27 Mar, 2013 1 commit
  31. 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 fo...
      226037da
  33. 15 Mar, 2013 2 commits
  35. 09 Mar, 2013 1 commit
  37. 04 Mar, 2013 2 commits
  39. 03 Mar, 2013 1 commit
  41. 22 Feb, 2013 1 commit
  43. 20 Feb, 2013 1 commit
  45. 04 Feb, 2013 1 commit
    • Stefan Tauner's avatar
      Fix building for MacOSX · e038e908
      Stefan Tauner authored 
      
- Add a new macro named IS_MACOSX to hwaccess.c and use it to enable iopl().
  This was broken since r1638. This fix does *not* restore the very permissive
  concept where iopl() was activated in an #else branch that was inplace before
  r1638.
- Make printing the image file's size in flashrom.c platform independent.

Bonus: remove definitions of off64_t and lseek64 which are not necessary
anymore for about 1000 commits.

Thanks to SJ for reporting the issue and testing the solution.

Corresponding to flashrom svn r1648.
Signed-off-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: default avatarStefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
      e038e908
  47. 02 Feb, 2013 1 commit

Powered by Integricloud