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 Harboe
http://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 write

jtag 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



Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to