On Dec 10, 2008, at 10:26 AM, Øyvind Harboe wrote:
On Wed, Dec 10, 2008 at 7:00 PM, Rick Altherr <[EMAIL PROTECTED]> wrote:On Dec 10, 2008, at 4:41 AM, Øyvind Harboe wrote:Hm.... I think perhaps the "jtag -expected-id" needs rethinking. The ID check should be in the target configuration script and not in C.The actual check is fine being in C. There is no need to force the retrieval of the ID and comparison into a script.This is not about the language, this is about the target configuration script interpreting the meaning of an ID.
Sure, many decisions based on the ID value retrieved can be handled in the target script.
The polymorphic approach to this problem is to push the handling into the "subclass", i.e. tcl in this case.The target script can accept multiple target id's and also output sensible target specific error messages or do whatever else is approperiate.We could just as easily allow multiple -expected-id options and compare against the list. Target specific error messages don't necessarily seem appropriate, but could be implemented as a jtag tcl event when a jtag tapdoes not match any expected ids.The point is that we shouldn't have to modify the C code when a new targetcomes along. Any fixed scheme in C will have the limitation that the target configuration script can't override it.
Agreed. I just want to make sure that we don't force every target script to add an ID check. The values passed to -expected-id should be used in a straight comparison in C and the result of the comparisons (match or no match) should be returned as a jtag event.
at91rm9200.cfg seems to be another case of where the standard expected-id breaks down.Can you provide more details on how it fails to work in that case?Not really, I just saw that it had special handling in the .cfg file already, so we're already heading down this road.Thoughts? How about adding a jtag tcl event to handle a discovered id?I see no harm in having such an event. We should also have a corresponding"id did not match any expected values" event. They can be used fortarget-specific error messages or for special circumstances (e.g. if id isX, we need to do Y for it to function).I want to push the interpretation of ID into the target configuration script,so the C code should do as little as possible here, just hand it to the target configuration script. There could be a default tcl even that can be overridden that checks that the ID matches.
I think the C code should distinguish between an ID match and mismatch. What should be done in those cases is up to the target script. So, -expected-id just builds a list of known IDs that the C code compares the tap's ID to. If the tap's ID matches one of the expected IDs, the jtag match event is fired with the ID that matched. If the tap's ID fails to match any of the expected IDs, the jtag mismatch event is fired with the tap's ID. If no jtag mismatch event is defined, a mismatch should cause an error as it becomes an unexpected event at that point.
This scheme lets the target script handle any target-specific functionality based on tap ID while not forcing every target script to implement it.
-- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer
-- 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
