diff options
author | David Brownell <dbrownell@users.sourceforge.net> | 2010-04-04 00:42:05 -0700 |
---|---|---|
committer | David Brownell <dbrownell@users.sourceforge.net> | 2010-04-04 00:42:05 -0700 |
commit | 876bf9bf4cd5fc2640d91811fb69c0d36f9e2c18 (patch) | |
tree | 5baff955b5886bd71d66bc950677448d672182a0 /tcl/chip/st/stm32/stm32.tcl | |
parent | 88fcb5a9ef971e54166de7cd16a3b0be20113b82 (diff) | |
download | openocd_libswd-876bf9bf4cd5fc2640d91811fb69c0d36f9e2c18.tar.gz openocd_libswd-876bf9bf4cd5fc2640d91811fb69c0d36f9e2c18.tar.bz2 openocd_libswd-876bf9bf4cd5fc2640d91811fb69c0d36f9e2c18.tar.xz openocd_libswd-876bf9bf4cd5fc2640d91811fb69c0d36f9e2c18.zip |
target: are we running algorithm code?
Fixing one bug can easily uncover another .... in this case,
making sure that we properly invalidate some cached NOR state when
resuming arbitrary target code turned up an issue when the code
wasn't quite arbitrary (and we couldn't know that, but some parts
of OpenOCD assumed the cache would not be invalidated.
Specifically: some flash drivers (like CFI) update that state in loops
with downloaded algorithms, thus invalidating the state as it's probed.
+ Add a new target state flag, to record whether the target is
running downloaded algorithm code.
+ Use that flag to add a special case: "trust" downloaded algorithms
not to corrupt that cached state, bypassing cache invalidation.
Also update some of the documentation to stipulate that this flavor of
trustworthiness is now *required* ... not just a fortuitous acident.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Diffstat (limited to 'tcl/chip/st/stm32/stm32.tcl')
0 files changed, 0 insertions, 0 deletions