On Tuesday 12 May 2009, Øyvind Harboe wrote: > Could we make an interface driver in OpenOCD that would > be able to use the urjtag device layer?
I had similar thoughts. I thought folk more expert in JTAG would be better to explore such things. There's this Øyvind guy at your company, for example ... ;) There's an interface layer in URjtag, with things like ft2232 and parport support; plus of course JTAG calls. An alternate question would be: couldn't the OOCD core be replaced with the URjtag core? Or vice versa? (NOT that I'm proposing that be done. I'm just pointing out functional similarities. Projects won't necessarily merge or cooperate like that; nor should they. Having some competition is good.) The URjtag stuff uses a different strategy for setup: it detects the devices on the chain, then configures itself based on their IDs. (Using either its own config files, or BSDL if that's enabled.) The config files are purely descriptive, and can't say much ... reading between the lines, I've suspected a testing/SVF focus. Now, I actually prefer that model to the current OOCD model of needing to say "this is what you shall find". That's something of a PITA, speaking just as a user, especially for things which *can* be autoconfigured. And in fact, I'm not the only person who's found it handy to use URjtag to look at what's there, so they can come up with an OOCD configuration. BUT ... my vague practical experience suggests that maybe, just maybe, not *all* JTAG chains support that discovery model correctly. Making me think that the better model might indeed prefer autoconfiguring, but accomodate the "this is what you'll be seeing" model too. Plus, obviously, there will need to be backlinks from the discovered IDs into the config process. Like the "debug" versions of the DaVinci scan chains, which start (TDI) with an ICEpick -- with the actual SoC identifier, and hosting the boundary scan -- then add a device which we "know" is an ARM926ejs core even if it doesn't use ARM's manufacturer code, then an ETB11 which *does* use ARM's code. Likewise its non-"debug" sibling, which works like OMAP3 cores ... gotta talk to that router to get other cores into the scan chain, as those are the things that GDB will eventually talk to. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
