在 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.
Will test later on Monday. Now I am at home and do not have access to the hardware.