On Dec 10, 2008, at 11:38 AM, Øyvind Harboe wrote:
Why not allow the tcl config script to implement this? If you define the interface correctly, then this *should* be possible to implement, entirely, inside the target config script. Otherwise, you have not left enough control for the target script. I'm using a circular definition there, but hopefully it's clear enough... Any scheme you implement in C is bound to run into trouble with the first odd shaped CPU out there....-- Øyvind Harboehttp://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer
The _only_ piece I'm proposing to put in C is the comparison of the provided expected-ids against the id read from the tap. Forcing that out into user space means that _any_ target that needs to check for an expected id regardless of needing to do some action based on it will need a target script. Instead of:
jtag newtap $_CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f - expected-id $_CPUTAPID
you would need to writejtag newtap $_CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f -event id {
if { [$ID == $_CPUTAPID } { return true } else { return false } }That just complicates the normal case for no reason. If you leave the expected-id comparison in C, you can still do things like:
jtag newtap $_CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f - expected-id 0x05b0203f -event nomatch {
if { $ID == 0x15b0203f } {puts "ERROR: info about having JTAG select jumper in the wrong position"
} else { puts "ERROR: unexpected ID: $ID" } return false }That encapsulates the at91rm9200 problem in a natural way. The expected ID for the target is specified and on success, nothing special happens. If it doesn't match, but it is another known value, we provide diagnostic info. If it isn't that other value, just fail with a generic message. It also means simple cases just don't specify either jtag event and current configs continue to work.
-- 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