On Sun, Jul 27, 2008 at 11:09 AM, Dominic Rath <[EMAIL PROTECTED]> wrote:
> On Saturday 26 July 2008 10:55:43 Øyvind Harboe wrote:
>> I'd like to retire reset "run_and_halt" and "run_and_init",
>> they are completely redundant.
>>
>> This simplifies the target_process_reset code and also makes
>> the documentation of reset less noisy.
>>
>>
>> This would leave us with three atomic reset modes:
>>
>> - reset run
>> - reset halt
>> - reset init
>>
>> the final one is really just a convention.
>>
>> reset run_and_halt can easily be synthesized from e.g. GDB:
>>
>> monitor reset run
>> monitor sleep 100
>> monitor halt
>>
>>
>> Additionally we're going in the direction of target configuration
>> scripts being able to override reset to a greater degree, so
>> the operations run, halt and init can be implemented pretty
>> much in any way that the target configuration script defines.
>
> Three lines, or alternatively using a script, isn't really a user-friendly
> replacement for a "reset run_and_halt".
>
> You once mentioned that you'd like "reset halt" to be synthesized by
> requesting halt if the target didn't enter debug state within a certain
> timeout.
Already in there.
> That would at least take care of e.g. LPC2000 targets, i.e. a user
> would just do a "reset halt" instead of "reset run_and_halt".
>
> But on targets that are able to "reset halt" it would be a lot more effort
> if "reset run_and_halt" is the desired behaviour (e.g. because the startup
> code is known-good to set up the clocks, sdram etc.).
Just like we have "init" script/event today, we could have a corresponding
run/halt/init scripts.
This would remove the raison d'etre for run_and_halt/run_and_init?
i.e.:
target_wait_state(target, TARGET_HALTED, 5000);
if (reset_mode == RESET_INIT)
target_invoke_script(cmd_ctx, target, "post_reset");
if (reset_mode == RESET_HALT)
target_invoke_script(cmd_ctx, target,
"post_reset_halt");
if (reset_mode == RESET_RUN)
target_invoke_script(cmd_ctx, target, "post_reset_run");
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
