On Thu, Nov 19, 2009 at 22:01, David Brownell <[email protected]> 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.
This is a misunderstanding due to my imprecise choice of words. I used target layer to refer to anything that uses the core.c interface to send JTAG commands. My comment above meant exactly the same thing as the one you quoted at the end, which I think you understood correctly. > 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. Yes I agree. >> 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. > Just to clarify the whole issue once more, my proposal was actually three different things: 1. Making the use of scan_field safer by providing standard handlers for the most common cases. This not only helps with the readability and reduces trivial copy&paste errors. It also makes it much simpler to rewire the underlying scan_field in a later step. 2. Eliminating the global variable jtag_command_queue. The existing jtag_add_... commands would remain similar but would operate on a local copy of the queue. jtag_execute_queue then receives the pointer to that local copy as parameter instead of using jtag_command_queue. The last user then disposes of the command queue. The advantage here is a cleaner modular approach. For example this makes scripting complex JTAG sequences possible without worrying about interference from polling. In theory this also allows for the use of multiple JTAG interfaces. With this approach it is also possible to offer an asynchronous jtag execution mode (if someone needs such a nightmare). 3. Break up jtag_add_dr_scan etc. This works best in tandem with (2). The general idea is not to pass one array of scan fields but to pass them in separate function calls (which would mimic, but replace the ones in (1)). To output a 7 bit field the caller just hands the value to the function and doesn't bother about allocating space. To turn jtag_add_?r_scan inside out like this requires its states to be kept somewhere so that plausibility checks and bypassing can be done. The local copy of the jtag_command_queue would be ideal for that (although it would also work by adding even more global variables). The caller then does something like this: jtag_queue_t * q = jq_alloc_queue(); jq_statemove(q, TAP_IDLE); /* This is just a placeholder for a good solution to deal with the fact that the initial TAP state is not known until jq_execute(). */ jq_set_tap(q, my_tap); /* set the tap to be implied by the following functions, until the next jq_set_tap() */ jq_ir_scan_start(q); jq_field_u32_out(q, 5, some_instruction); jq_dr_scan_start(q); jq_field_u32_out(q, 7, my_value); jq_field_u32_outin(q, 3, another_value, &return_value); jq_execute(q); /* callee frees q and associated data */ Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
