在 2013年4月20日 星期六 11:36:53，Stefan Tauner 写道：
Thanks for testing. This is quite odd: we do the right thing IMHO. The relevant code is in spi25_statusreg.c spi_disable_blockprotect_at25df() calls spi_disable_blockprotect_generic(flash, 0x0C, 1 << 7, 1 << 4) In the beginning the status register is 0x1C, i.e. the status register is not locked, the hardware protection pin is not asserted, only the write protection bits are set. spi_disable_blockprotect_generic() correctly detects that and tries to set the protection bits to 0 by trying to write 0x10 (not touching the r/o WP pin bit), but that apparently has no effect.
Interestingly here the initial contents of the status register are what we would expect them to be after unlocking(!). Maybe the chip reacts too slow? Do you have another explanation for that behavior?
The patch below adds a delay of five seconds after trying to write to the status register for unlocking.
It seems the delay patch did not work: http://paste.flashrom.org/view.php?id=1623
Without patch 3927 or the delay patch, but with the patch showing the register: http://paste.flashrom.org/view.php?id=1624
That shows without patch 3927 the register has been turnned into 0x10 successfully.