On Thu, Jun 25, 2009 at 12:06 AM, David Brownell<davi...@pacbell.net> wrote: > On Wednesday 24 June 2009, Duane Ellis wrote: >> > So maybe you can answer this ... What does the "arp_" prefix in >> > various commands represent? >> > >> > "Address Resolution Protocol" was my first reaction ... but >> > that doesn't seem relevant to JTAG. ;) >> >> That name "arp_" was coined by my self an Oyvind last year when we where >> trying to introduce "Reset events" and all the other Jim type events. >> >> The "ARP" - stood for: "Advanced Reset Process" - .... > > > On Wednesday 24 June 2009, Ųyvind Harboe wrote: >> The idea is to have a prefix to low level fn's that the higher >> level tcl reset proc uses. >> >> As such the choice of prefix is arbitrary. > > OK, first question answered. Thanks. > > Next ... > > > 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. 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 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. > 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. > - 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? [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? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
