>> 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.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
