On Sat, May 03, 2014 at 06:44:24AM -0700, Duane Ellis wrote: > On May 2, 2014, at 11:19 PM, Paul Fertser <[email protected]> wrote: > > Your MUA is apparently doing strange things: > > mac EMAIL - and I’m probably trying to be polite and screwing it up and > making it worse. I hope this one is better, no goofing around with replies
Yes, now it looks more common, just linebreaks are still missing (usually MUAs break lines on the 72 columns automatically). I know OS X comes with a fully functional Emacs distribution (Gnus included) ;) > >>> BTW - also need a solution for a JTAG tap that is accessed via the DAP > >>> -> JTAG_AP interface.. > >>> > >>> ie: Openodd -> interface -> SWD mode -> DAP -> JTAG_AP > >> > >> That DAP with other processors via the JTAG_AP port. > > > > What if OpenOCD would expose JTAG_AP ports via a regular socket with a > > JTAG-level protocol > > It should provide a standalone tap-struct - just like all of the > other taps, no different. Probably will need to introduce a > “jtag-ops” function pointer to the tap-struct, much like the dap has > a dap_ops structure. I'm not sure we understand each other well here. Let me try to clear the confusion. If I understand it right, JTAG-AP is a special AP (accessible via DAP) which provides access to a "hidden JTAG chain", and that hidden chain is no different from a real JTAG chain as in every device on the said chain has a JTAG state machine, IR and DR etc. So if OpenOCD gains support for this kind of AP, it'll need to basically handle two completely different JTAG chains at the same time. I think that implementing that would be unreasonably hard (due to lots of assumptions, global variables etc) and on the other hand running a separate openocd instance with special interface driver would be quite easy, hence my proposal. > > It seems that would look like a sane layering matching real hardware; > > that is the intent - there is one dap, with cortex_A and cortex_M > and other CPUs attached via the AP > > the problem right now is this: cortex_A has private DAP struct, and > the cortex_M has a another private DAP struct, and if support for > JTAG-AP is added, it should not have another private DAP struct - > because there is only one DAP. Then my proposal is this: 1. When "target create <name> cortex_[ma]" is called with a "-chain-position <tapname>" (actually, "swd newdap" is cheating by creating exactly the same tap structure as "jtag newtap" does, so it would be applicable as well here; multidrop swd would be creating N tap structures just as many taps can be created with jtag now), cortex_* target code callocates a new reference-counted "dap" structure and stores a pointer to it; 2. When "target create <name> cortex_[ma]" is called with e.g. "-master-target <target-name>", cortex_* code receives a pointer to the "master" target, fetches the dap pointer from there and stores it inside its private struct. So changes to the generic target code would be minimal here, compatibility with all the existing configs would be preserved, and for multi-core devices a new capability of sharing the DAP would be created. Or am I missing something? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[email protected] ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
