On Sunday 10 January 2010, CeDeROM wrote: > On Sun, Jan 10, 2010 at 10:35 PM, David Brownell <[email protected]> wrote: > > It's not in 0.4 but I've been looking at some of the infrastructure > > work that's needed to incorporate it. Various non-mergeable patches > > have been sent around. > > > > I'll post some more later, but for now I see several areas that can > > work somewhat in parallel until they combine: > > (...) > > Well, here goes the science-fiction part :-) Some time ago there was a > concept to join two big open-source projects named OpenOCD and UrJTAG > to become one giant.
Neither one is all that large. ;) > OpenOCD could then serve a high level logic and > UrJTAG provide low level access to the hardware devices and interface > dongles. Do you guys think this could be accomplished, or those two > projects gone far different way? I don't think anyone has really looked at what would be involved, but similar ideas have circulated. It might indeed be a good thing to share some of that low level code. There's a lot of stuff OpenOCD does which UrJTAG doesn't, and I'd not be surprised to learn the converse is also true. I'm not sure any breakdown could be quite that simple. They don't do much for debugging; that's a primary focus for OpenOCD. Such issues bubble up through many layers of interface. We don't do much for boundary scan; ditto. > Maybe this SWD could be a good > starting point if there is a lot to be done on a OpenOCD side, while > UrJTAG has these interfaces organised already... I don't believe UrJTAG has even looked at SWD ... it's not JTAG, after all. It couldn't host boundary scan applications or other general purpose tools. > Or maybe it is not > the time yet and some further development should be done (ie UrJTAG as > a library) before merge? Even so - maybe this is a good time to > prepare some API in OpenOCD for JTAG access Zach's been looking at some of the issues there, but I think the's been focussed on the mechanics of it: take current interfaces, get them so they can be libraries called by other code. That's clearly a problem that would need to be solved ... but not the only one, and IMO not really the hardest one. The hard part is figuring out what such a programming interface would look like. Being able to switch modes (SWD to JTAG, JTAG to SWD) is one thing. We also have different implementation strategies (ZY1000 working quite differently than say an FT2232 based dongle, or bitbanging through a parport or whatever); AFAIK more than UrJTAG. Getting two projects to converge on such an interface ... lotta work!! > - to support different > access modes (current jtag and future swd) or even methods (supplied > by externel UrJTAG-based library)..? I dont know OpenOCD internals but > maybe they are somewhat similar to these in UrJTAG [1]..? If you're thinking of SWD as anything more than an ARM-specific debug protocol, re-think ... There's a register access model that's part of SWD, part of the "ARM Debug Interface v5". One talks to a Debug Access Port (DAP), which generally provides memory-mapped access to most things on a SoC, including debug hardware. Same thing with using JTAG to talk to those cores. The focus is on DAP support, not transport options like SWD or JTAG. See: http://infocenter.arm.com/help/index.jsp under "CoreSight and ETM Architecture Specifications". You can download the PDF after registering. - Dave > > [1] > http://urjtag.svn.sourceforge.net/viewvc/urjtag/tags/URJTAG_0_10/web/htdocs/book/_jtag_commands.html _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
