All,
I've been working some on support for the beagleboard (oma3530) - you've
seen quite a bit of traffic on the mailing list about this.
I need to break these changes in two parts.
One thing that is shaking out of this is the removal of the "tap index"
idea, and going with a uniform "tap name" scheme.
Specifically - this what Oyvind mentioned previously:
https://lists.berlios.de/pipermail/openocd-development/2008-October/003416.html
My plan:
One can refer to the tap by *NAME*
Or (for legacy reasons) by NUMBER
TBD - and it is a minor issue:
Should that number be the number in the ALL chain
OR the index within the *active/enabled* taps?
Good News: The change is rather straight forward
Bad News: The change is pervasive - and throughout openocd.
I *STRONGLY* propose the following changes:
1) Rename the structure:
OLD: typedef struct jtag_device_s jtag_device_t;
NEW: typedef struct jtag_tap_s jtag_tap_t;
All jtag taps are kept in a linked list, head:
OLD: extern jtag_device_t *jtag_devices";
NEW: extern jtag_tap_t *jtag_all_taps;
2) There is a ghost variable (that holds the length of the list)
OLD: extern int jtag_num_devices;
NEW: extern int jtag_num_taps;
Rational:
My thinking is: device = chip.
In the beginning... this was true: 1 DEVICE = 1 TAP.
Today - its common place to have 3 to 5 taps on one device.
Each of these are not separate "devices" - they are really "taps".
3) All over the place - and in many many different ways and places -
TODAY: Each tap is referred to by its index position within the jtag chain.
ie: The value 5 indicates 5th tap in the chain.
This goes by many different names.
(1) file: "src/target/target.h", struct target, element:
chain_position
(2) file "src/target/*[ch]" - example: xscale.[ch], "chain_pos"
(3) file: "src/flash/str9xspec.[ch]" 'chain_pos', and "devarm" and
"chain_pos+2"
(4) file: "src/jtag/jtag.h" - struct scan_field_t, element: device
I believe all of these should become just a "tap pointer".
(exception being the "str9xpec" - which fiddles with the list in bad ways).
Comments?
-Duane.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
