On Thu, Feb 4, 2010 at 6:55 PM, David Brownell <[email protected]> wrote: > On Thursday 04 February 2010, Edgar Grimberg wrote: >> > flash protect 0 0 1 off >> Can't unprotect write-protected pages. > > That's because on Stellaris, the write protect bits are write-once; > it rejects *ALL* requests to unprotect, since the hardware doesn't > support that operation. (You can perform the "recovering a locked > device" operation, erasing all the flash and those bits too, but > that's not currently doable with OpenOCD.)
Yes, I understand how the hardware works. My point was that unlocking an unlocked sector should be a noop, not an error. > Another issue is that the OpenOCD core code doesn't use its cache of > protection data when deciding what protect/unprotect ops to perform. > > To some extent that's appropriate; firmware can update that status. > If that NOR core code starts using that cached data, it should make > a point of invalidating the cache when it resumes target execution. > (By setting the per-sector protect flags to "unknown".) If it used > that cache in a safe way, your "protect_check; unprotect" sequence > could safely detect and handle that "it's already unprotected" case. What bothers me here is the different behavior of the same command for different flash drivers. For example, SAM7 flash driver is peeping now and then at the flash to detect the actual status of the sector protection. I'm not trying to argue what method is best, what I'm saying is that the commands should be as similar as possible across different flash chips. > You didn't mention which Stellaris chip you're using, but if it's > an lm3s3748 (a DustDevil) a chip erratum affect behavior of the > flash protection bits. The driver doesn't currently try to handle > that erratum; but arguably it should. I'll make a ticket for that. It should go nicely in 0.5.0 Regards, Edgar -- Edgar Grimberg System Developer Zylin AS ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html Phone: (+47) 51 63 25 00 _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
