> > Does it seem to you like the reset process is flexible
> > enough yet?
>
> The idea is that those targets where the tcl reset
> proc doesn't cut it would implement their own
> tcl reset proc from scratch.
That seems undesirable when some key improvements can
be more generically available.
Like for starters, either a TAP event on TLR entry
or a settable parameter saying how many TCK cycles
must be issued in TLR before issuing JTAG commands.
What we have now is "jtag_ntrst_delay milliseconds",
without clocks going. "jtag_ntrst_clocks" would
address documented ICEpick and PXA255 constraints.
And there are no doubt other similar small tweaks.
Note the scaing problem with needing target-specific
rewrites of ocd_process_reset: it's impractical to
combine two such targets on one board...
> 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 ... :)
> 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.
> > I'm thinking .. no:
> >
> > - All those reset events go to debug targets ... but
> > there's at least the ICEpick example, where a JRC
> > needs 100+ TCK cycles after entering TLR, and it's
> > easy to find others. Loading an FPGA, for one.
> > Those aren't targets; so no events...
>
> I'm not even sure that the reset concept even applies to
> an FPGA. For Altera Nios I'd first like to program the
> FPGA, then reset the CPU.
If I've got an FPGA *not* programmed with a Nios core,
that model doesn't work. :)
That issue isn't entirely "reset". It's "initialization",
which is a separable chunk of reset processing. For a
Nios core you could have "system reset" requiring both
"FPGA init" loading the core, and then "core reset".
But other FPGA bitstreams might not have a target.
> > - I was looking at DM355 documentation and it clearly
> > distinguishes "cold" resets -- both TRST and SRST
> > get cycled -- from "warm" ones -- SRST only. We
> > don't seem to have a clean way to do "warm" today.
>
> soft_reset_halt?
No, that's a different beast. It applies to the current
target and doesn't involve SRST.
One reason to want a warm reset is that it leaves all
the debug/jtag stuff alone. Maybe you tweaked some
settings so that some things become observable during
the reset/reinit sequence.
> [I've deleted those items where I had no useful input
> at this time]
>
> > And I suspect that if I looked around a bit, I'd find
> > more such cases where the reset model isn't (yet!)
> > advanced enough. Thoughts?
>
> A target/board config file can reimplement the
> reset proc from scratch. How far does that get you?
As a "user", way deeper into the undocumented innards
of OpenOCD than I want to be. ;)
As a developer, it's hard to say without doing it.
My initial reaction is that the reset processes are
not yet factored well enough to support everything
that I've happened across. But experimenting with
a few individual targets should help identify more
of the holes.
What I'd like to see is a kind of "reset toolkit"
which would make that practical. But it's not
really there yet. "Reimplement ocd_process_reset"
is not a scalable approach.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
