On Dec 11, 2008, at 3:55 AM, Duane Ellis wrote:
duane> ================================== duane> Here is the *SIMPLE* thing that needs to happen. duane> (1) There needs to be a new target event. duane> This event should happen when all taps have duane> been "re-id" aka: when the chain is validated. rick> I don't think the target is the right place for this.It is the right place, this gives the *TARGET* something that the *TARGET* can do after the jtag tap chains have been validated.If they choose to do *NOTHING* so be it.If they do something - ie: Like make sure "TARGET.foo" is *REALLY* the chip you think it is... then even better.
Fair enough. For something like the at91rm9200, at the tap level, both the debug and boundary scan mode IDs are valid, but at a target level, only debug is useful.
Adding *ANOTHER* *ADDITIONAL* mechanism - for *TAP* events - yes, that is possible.But - that gets messy.
As my other patch shows, such a mechanism simplifies interacting with a JTAG route controller, so the mechanism would already be in place.
Please recall our earlier discussion about "taps as objects" we came to the conclusion that "taps as objects" was not a good idea,m the problem was namespace issues.
I still believe namespaces a big problem. That said, having separate namespaces doesn't preclude "taps as objects". From a programmatic view, target objects could be contained under a "targets" global and tap objects could be contained under a "taps" global. That handles the namespace problem but allows both to be treated as objects.
Doing this should also make adding other protocols like SWJ, I2C, and SPI easier. The tap objects can be a generic struct that contains a type identifier. This type would indicate which protocol it uses and also indicates the other members of the struct. Then, each protocol would have a top-level command similar to the "jtag" command. That command would have a "newtap" subcommand that takes the appropriate operands for that protocol. Then when creating a target, the tap is specified. The target could inspect the tap to determine if it can use a tap of that type. That would provide sufficient decoupling between the protocols and the targets to allow new protocols to be introduced with relative ease.
==============Rick> The id is tied to a tap which may or may not be a target. If we tie it to a target event, how would you do an id check for a PLD? Via the list of "-expected-id" patch that you just posted to the list.
That would only prove that one of the expected IDs was matched during chain examination. Ostensibly, a PLD could have 2 JTAG modes that change the ID it reports similar to the at91rm9200. Thus, the target tap-validate event would need to be replicated for PLDs, NAND, etc to allow those types to report additional information such as "Pin 5 is grounded which places the PLD is run-only mode. To program the PLD, connect pin 5 to Vcc."
--Duane.
-- Rick Altherr [EMAIL PROTECTED]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
