> > The protection state will never be known until a protection check is done > anyway.
The protection state will never be known for sure. What if the user is running an application that changes the protection status? Protection check doesn't reflect the protection status of the flash. On the other hand, for other drivers, shouldn't flash info do a protection check on the background? Otherwise the information presented by the flash info command is *wrong*. > The default state is more likely to be unprotected (factory default), as few > users set the write protection anyway. Right, this is what I'm doing in the patch. > Issuing a warning about the str7 protection status is a bit misleading. > It is 'valid' after a reset, but any changes after the reset are not > reflected in the flash info cmd. No the warning is real. The flash info command *happens* to display the correct information after reset, but it has nothing to do with peeking the *real* value from the hardware. I'm a bit passionate about this because *I* was mislead by the text displayed by flash info. I don't know how else to tell the user to move along because this is a known issue. > The gdb-flash-erase-start can be removed as you are already removing the > protection in the reset init script. I'm a bit reluctant to erase. One of Zylin's customers pointed out that we should pay a lot of attention to backwards compatibility. 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
