Øyvind Harboe wrote:
> Looks good to me.
>
> I saw that your scheme above also handled reordering the
> chain, but didn't quite see how you achieved that.
>
>
I presume that reply was to me... the mail thread order got wacky.
It does not really reorder the chain - but it could easily do so.
The idea is this:
(A) there is a linked list of jtag devices. HEAD = global variable:
"struct jtag_device_t *tag_devices";
(B) As that list is built - there is an implied order to that list, ie:
the order it was built.
(C) That inherent order is used by the function:
struct jtag_device_t *jtag_get_device( int num );
(D) Remember how the "target became an object" with the earlier change?
That needs to happen too.
(E) During initial configuration, the "tap object " is given a
"position" in the chain.
For example - Some ARM926 chips have different internal orders. Others -
chips like omap/beagleboard have taps that appear and disappear.
Since the "jtag tap" is an object - the "tap objects" in the omap/beagle
board could be enabled & disabled via their "tap object"
And - well one could do other things with the tap object, for example
change the order the tap is in by using the "configure" command.
(F) The idea is - Later, when the entire chain must be itterated in some
order a list is built. That list is *temporary* - and rebuilt again and
again and again. Why? Incase some body does something weird with the
'tap object' command - like disable something, or change the order of
something.
-Duane.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
