Yusuf Ibrahim Ozkok writes:
Yusuf> Thanks for your reply. I'm also still working on, to find out Yusuf> the magic. And I'm getting crazy, since it's a very easy Yusuf> issue I couldn't over come it :-(
Yusuf> I have downloaded the last version of cfi_flash.c from Yusuf> CVS. So now it includes all the accepted patches.
Yusuf> Below you can find the debug output. I defined "DEBUG" in Yusuf> include/common.h. I couldn't see any other command (0xff as Yusuf> you said) between 0x60 and 0xd0.
It was in your previous mail. Probably some lines were not printed so it looked like a 0xff in the middle.
Yusuf> So there shouldn't be a command sequence error actually.
Yusuf> An other thing, I couldn't understand why we need to re Yusuf> protect all other sectors again in "flash_real_protect()".
Yusuf> There is a comment in the code /* Intel's unprotect Yusuf> unprotects all locking */
Yusuf> But I tried it and found that other sectors are not being Yusuf> unlocked!
...
It depends on the chip. For some chips, all sectors are unprotected, for others (like the chip you're working with) only one sector is unprotected. What I see from the debug prints is what I suspected: unprotect works OK but protecting already protected sector results in time-out (though Intel's docs don't say it's a forbidden operation). Note: time-out appears after 0x60 0x01 sequence, not after 0x60 0xD0. If you try to write/erase the sector which you tried to unprotect, I think you'll succeed. All sectors (on this chip) are protected after power-up so `protect off' will try to re-protect them. Correct operation would be reading sector protection status (it's available after Read ID command) and comparing it to the flash info structure. If the flash info indicates that the sector should be protected but it's unprotected, only then should the driver issue protect command. As a "quick and dirty" workaround, just `protect off all'.