On Sunday 20 July 2008 19:25:07 Øyvind Harboe wrote: > I've got some thoughts on defining a crisper interface between the > target_process_reset() and the target. > > - the idea is to let the target be ignorant of reset modes. Reset > modesrun, init, > halt, run_and_init, etc. is something that is built on top of the target > reset support. > - a target is told to assert reset into the halted or into the running > state. - a target may fail to reset a target into the halted state, in > which case it is running. Why it fails to do so isn't important. > - the target_process_reset() will detect that the target is running > instead of halted and issue a halt if approperiate > - since reset is now asynchronous, reduce usage of event callbacks > and wait for halt + synchronous function calls more. This will make > it clearer what happens when. > - from a scripting api point of view, there will only be two types of reset > that can be issued: reset run or reset halt. init scripts is built on top > of the latter. from a scripting point of view there is no need to > distinguish between a failed target reset+halt and reset+run&halt.
Some points to consider: - from the (knowing) user's point of view, there is a difference between a failed reset+halt and a reset+run&halt, especially when a target is supposed to support reset+halt. At a minimum the user needs to be informed about a failed reset+halt. - multiple targets on a single chain make reset a lot more difficult - not sure how this works these days, but if you're going to rework reset anyway, this might be worth some extra care. Best regards, Dominic _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
