Re: [Openocd-development] Jtag Tap "chainposition" vrs "named position"

[Rick Altherr]

On Nov 24, 2008, at 5:17 PM, Duane Ellis wrote:

All,


seen quite a bit of traffic on the mailing list about this.

I need to break these changes in two parts.


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?

I've been working some on support for the beagleboard (oma3530) - you've One thing that is shaking out of this is the removal of the "tap index"

Probably should be position in the list of ALL taps. That reflects how it works today.

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;

Is this actually necessary? Are we traversing the list so frequently that it is a performance win to keep the number of taps rather than doing an iteration? I've found that things like this tend to be forgotten when making changes to the list and so they should be avoided unless they are necessary for other reasons.

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".

Correct, taps are jtag endpoints that may be enabled and disabled. It is useful to group taps for organizational purposes be it a chip, board, etc.

3)  All over the place - and in many many different ways and places -



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"

"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".

TODAY: Each tap is referred to by its index position within the jtag chain. (3) file: "src/flash/str9xspec.[ch]" 'chain_pos', and "devarm" and (exception being the "str9xpec" - which fiddles with the list in bad ways).

Agreed

Comments?

-Duane.


_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

--
Rick Altherr
[EMAIL PROTECTED]


 -- Unsigned

"He said he hadn't had a byte in three days. I had a short, so I split it with him."

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development