Re: [Openocd-development] Advanced Reset Process

[Duane E. <op...@du...>]

>> This avoids switching 
>> programming paradigm from procedural to
>> event based, i.e. we could add events until
>> the cows go home and still miss that crucial
>> event for the next target.
>>     
>
> I'd call the current reset "events" procedural
> hooks, myself.  Heck, they don't even accept
> any parameters ... :)
>   

The original idea/concept for the events was Tck/Tk "bind" - what i 
wanted to do was add support for "%T" for target, and a host of other 
things - much like Tk has "%w" for window name, and %x and %y for event 
location - stuff like that. But never got around to it. Mostly because I 
wanted the event stuff to 'gel' a little.

>> I don't believe that it is possible to *ever*
>> add a reset event that is flexible enough for
>> all future targets.  I'm in favour of adapting OpenOCD
>> as we go along rather than create a hugely complicated
>> monster reset scheme that still won't catch the next
>> jtag router from hell problems.
>>     
>
> Routers weren't the only, or even the main, set
> of motivating examples...
>
> But you seem to agree that the reset process
> still has holes that need fixing ("adapting");
> so that question is answered.
>
>   

Why don't we re-describe the reset process completely.

ie:    We define a few models - ie: (A), and (B) - and call those complete.
(That would handle probably 90% of the simple situations).

Then - allow the "reset" command to be 100% re-written, perhaps what we 
need is:

proc reset { } {
    jtag  assert  TRST  SRST
    jtag  sleep-msecs  250
    jtag de-assert TRST
    jtag ... scan command
    jtag .. scan command
    jtag .. scan command
    jtag de-assert SRST
}

This would *DE*COUPLE* the entire process.

We could then - add a few *TARGET* specific commands, ie:

    $TARGET  reset-action NAME ... parameters

For example - ARM7/9 - support to do "reset-halt", where you stop the 
CPU @ the reset vector.

--

Today - the C code *controls* and *drives* the reset sequence.

I'm suggesting we turn that inside out - and make the TCL code - drive 
the reset sequence - via commands above.

There would be a few *default* reset sequences - in tcl... that one 
could point "proc reset" at.


-Duane.