On Thursday 04 February 2010, Edgar Grimberg wrote: > > 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've observed that pushing lots of requirements onto drivers tends to produce lots of driver bugs. :) Better IMO to implement such behaviors in driver-neutral ways. And the sam7 driver has a few issues that make me dislike using it as any paradigm of goodness. Something about required parameter lists that consist of an armload of pointless zeroes ... ;) > 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. And I won't disagree. You may have noticed I've been working on applying that argument to ARM targets ... presumably there are a few issues like that with NAND chips too. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
