On Sun, Mar 1, 2009 at 11:53 PM, Rick Altherr <[email protected]> wrote: > On Mar 1, 2009, at 12:08 AM, Dirk Behme wrote: >> The first and easiest idea is to add something like >> >> #ifdef OMAP3_SUPPORT >> /* Do 10 TCK in RESET state to enable OMAP3 jtag */ >> omap3_init() >> #endif >> >> to jtag_init_inner(). But this is quite hackish. There doesn't seem to be >> an interface to add processor specific pre-init functionality to >> jtag_init_inner() ? >> > > I'm not fond of device-specific code in C. The 'run_test' command available > in TCL should let you run any number of clocks in IDLE today. We have > talked about changing it to add an optional state argument, so you could do > something like 'run_test 10 RESET' and have it do 10 TCK in RESET. Then you > can use the reset-init event (exposed in TCL via the target event hooks) to > do that when OpenOCD does a reset.
While I do think this is clearly possible I think we are hitting a well known problem in computer history called the borken abstraction. A developer creates an abstraction but that does not work all the time. When an other developer hits a problem he needs to "break" in the abstraction to understand what is going wrong. A third developer who does understand the lower level jtag protocol gets even less satisfaction. He knows what he wants but can't. A fourth developers who want's to add support for this new piece of hardware not only has to understand the hardware and the TCL/openocd way of doing things but apparently also needs how to add TCL commands :p Anyway , it would be nice to understand what was discussed what will be picked up by core developers. IMHO it would be better to expose the CORE api's to TCL so anything IS possible v.s. what the developers needed at the time. I think that for the omap the svf based aproach might be easier to get working. I will try this next Greetings _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
