On Monday 08 June 2009, Dirk Behme wrote: > - Tell exactly what is broken (from a technical point of view, maybe > on a level a not so experienced OpenOCD engineer could understand...
Here's a start. Maybe other folk can add more. From the docs I have, I don't think Beagle actually needed standalone "endstate" since it was sufficient to require that the scan ops finish in a PAUSE state. I was doing this on a DaVinci, which AFAIK was the first product to use ICEpick-C. That should be simpler than on OMAP3, where issues like "we don't yet have full Cortex-A8 support" also crop up. Plus, there's boot mode where ICEpick configuration is not needed ... which also helps isolate issues. I'm going by this PDF document (rev 0.2 just now): http://tiexpressdsp.com/images/3/3c/Router_Scan_Sequence.pdf See the appended "icepick.tcl" script, which should eventually become sharable/library code. In no particular order, and with no expectation of completeness: - Can't handle IDCODE instruction for these DSPs, since the instruction length is 38 bits. Affects testing; I don't expect OpenOCD to ever support C55, C64x+, or C67+ DSPs! (I want to be able to look at *every* JRC port, to know that the code behaves in more than one single case.) - The current *model* of TAP enable/disable is a bit off. * There are two disable modes, but the code only has one right now. We should interpret the "-disable" option on TAP creation to reflect the state after exit from the JTAG Test_Logic_Reset state (doc fix for 0.2 IMO). The *desired runtime state* is a different beast, AFAICT. * Related, enabling TAPs is currently only done by a "jtag tapenable $TAP" command. It should be abstracted so it's done automatically in cases like initializing an ETM bound to a disabled ETB, and to re-enable after some code triggered TLR. - The current TAP enable code is incomplete. It needs to kick the target(s) asociated with that TAP; examine() it and maybe more. - That TAP enable code is also excessively trusting. It should verify that the TAP actually appears! And that it's the expected device. The latter implies different kind of chain validation than we have now, since it may not enter TLR. (Presumably we can immediately verify the IR length with IRSCAN. Though it'd be good to sanity check that we didn't somehow enable *two* adjacent taps. If we know the IDCODE opcode we should then be able to verify the expected TAP id.) - Similarly with TAP disable. It should verify that the TAP disappeared. (We don't currently know how to make the ICEpick-C taps go away, but I'm fairly sure we could find out ... even without a logic analyser watching what happens on the JTAG bus!) - I didn't see an obvious way to guarantee the expected 100+ TCK cycles after TLR. The cleanest way would be to define a new TAP event for TLR exit, and let the JRC provide a method that just does "runtest 100". - One of the header files says that interfaces may use arbitrary state transitions. I think that's got to be changed somewhat ... the new "pathmove" thing is not sufficient, given free running clocks. The hard and fast rule *here* must be: never enter RUN/IDLE implicitly. - Server can come up with the "current" target disabled. That shouldn't be possible. That's all for now. Comments from anyone who's looked at this before? - Dave # jrc == a JRC tap name # port == a port number, 0..15 proc icepick_tapenable {jrc port} { irscan $jrc 7 -endstate IRPAUSE drscan $jrc 8 0x89 -endstate DRPAUSE irscan $jrc 2 -endstate IRPAUSE drscan $jrc 32 [expr 0xa0002108 + ($port << 24)] -endstate DRPAUSE irscan $jrc 0x3F -endstate RUN/IDLE runtest 10 } _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
