On Wednesday 18 November 2009, Michael Bruck wrote: > I would actually prefer an API that is tightly linked to an > independent data structure that that builds up a jtag sequence in the > target driver and then executes it. All the commands would then work > on building up that structure and in the end it is handed over > directly to the jtag interface driver for execution.
That presumes there *is* a target. We have SVF and XSVF today, and there can be other tools that work more at the JTAG level. Plus, it's a bit awkward to be coupling address space access (memory read/write) to targets, considering that newer ARMs decouple them (via ADIv5) and so does, ISTR, Nexus. I'm not entirely sure what you mean to describe though. I'd like to see less baroque structures for the JTAG messages, and one part of that is clearly a need for more efficient bit vector handling. Along those lines, $SUBJECT is the wrong model too. When we want to work with 64 bit or 128 bit words -- or even just the 40-bit words common with older ARM stuff -- then we should be able to just pass those down. Thinking "8" or "32" focusses on the wrong stuff ... implementation details, not the concepts that will produce a better interface. > The current model does the same but essentially uses a global > variable. But presumably due to ownership issues the field data is > cloned for that global variable. If the jtag sequence structure is > owned by the target this (second) copy operation can be avoided as > well. I think I agree with what you're saying there. JTAG layer gets delivered a queue, which it processes and modifies in place (if required). For extra credit: some way to package queues with a bit of intelligence, so they could be downloaded into smarter controllers. Example, the polling loops which run in the background ... or between key steps of high level operations. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
