For the record ... I think the key open issue here is the need to refactor target code so that we have more general support for reset-without-SRST, using event handlers that know how to do that via JTAG (such as by forcing a watchdog reset). Maybe in 0.4.x ...
Once that happens, the other open bits should be easy enough to solve. On Wednesday 24 June 2009, David Brownell wrote: > > Does it seem to you like the reset process is flexible > enough yet? 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... We seem to have this one addressed for now ... two more events go to TAPs, sufficient for ICEpick configuration. I can imagine the "setup" TAP event being used to load an FPGA and then enable the targets associated with some CPUs that just got instantiated. > - 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. We can do that now if we want, via custom reset_init. > - In cases where there's no SRST available (*), there's > no alternate hook to trigger reset through JTAG. For > example, using JRC operations (I'm hoping to get some > documentation). Or with Cortex-M3, it seems that > some DAP operations can generate SRST too. Not there yet, but there's a proposal for how to model it and let targets stop hard-wiring "use SRST". > - Wondering why this old PXA255 board won't work with > current OpenOCD ... docs say that not only does it > need 35+ TCK cycles after entering TLR, but also > that the model is to keep SRST active while issuing > the first few JTAG commands. Current reset code > deactivates SRST at the same time as TRST. Partly resolved. Controlling the "basic" hard reset call through a Tcl script lets us perform some of the right stuff at reset time, and get past the first roadblock. The parameter to that script can be used too. I'm thinking we may want to tweak the current reset event sequence, and model; see below. PXA for example is one of many platforms that doesn't look to need such a hard reset ... an SRST-only (warm) reset shouldn't need to reinitialize all the debug stuff a TRST+SRST (cold) reset requires. > - I found some TI docs talking about "Wait in Reset" > capability of some systems, triggered by changing > the EMU0/EMU1 signals (which OpenOCD doesn't know > about) from "pulled high" to "one driven low". > Same kind of model as those PXA255 docs describe. Re EMU0/EMU1, once we have support for e.g. XDS100 (v1 or v2) we can add such support via Tcl procedures. As with PXA255, I'm thinking the reset sequence and model might need to change. Today we issue TWO hard resets by default, using SRST ... one should suffice. And the state of things between those resets is kind of fuzzy. We should be able to issue just one reset; not be required to use SRST; have better treatment of the two main models (either we can talk JTAG while SRST is active ... or not); and in general, be able to rely less on both SRST and TRST. > - Even when SRST *does* exist, I can imagine debug > scenerios where using it is the wrong thing. You > may just want to reset one component, not the whole > system. ... see above. > - Chasing that PXA thing I wanted to just issue a > reset with no target enabled. It didn't want to > do such a thing with only JTAG level stuff defined. Not sure if this got addressed yet. > 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? > > - Dave > > (*) As for example wherever TI's 14-pin JTAG connector > is used. My DM6446 board through 20-pin CTI to > 14-pin level shifting adapter; OMAP3 BeagleBoard. > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
