On Thu, Nov 19, 2009 at 10:01 PM, David Brownell <davi...@pacbell.net> wrote: > 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.
I'm working on an API which focuses on values(any size), rather than a particular bit width. Part of what I wrote went the way of my harddrive on my laptop while I was travelling these last few days... > 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. There is very little evidence to the effect that it would be worth the extra effort and complication to be more clever than today about handling long latencies. My main goal is to make the code a bit crisper and clearer. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
