Øyvind Harboe wrote:
> Sounds good to me.
>
Let me back up a few steps here.
There is a *SIMPLE* way to do this in TCL - it requires a couple
*SIMPLE* things be done.
{See below}
=================================
The original purpose of the "-expected-id" was to print a big-nasty
warning if the TAP id did not match.
Why did I add this? Because there was a *SLEW* of people trying to
figure out how to setup the taps and new boards and stuff.
We release new versions of OpenOCD - people try something - blah blah
blah - there is no standardized config script schema or and method.
This was a message to make the user go "OOH THAT DOES NOT LOOK RIGHT"
- perhaps that is my problem!
Hence, if the expected id is ZERO - nothing happens.
=================================
Perhaps: "-expected-id" was a bad choice of names.
Maybe, "-one-possible-valid-id" would have been better a choice.
For example - today - the code does *NOT* ignore Tap VERSION numbers
(the high nibble).
And that is problematic - the AT91RM9200 - has tapid version 0 for the
"arm debug config"
and tap version number 1 - for the "boundary scan mode".
So - obviously masking and ignoring the TAP VERSION is not going to help.
We specifically almost need a "-disallow-this-tap-id" in some cases :-(
boo hiss boo hiss.
=================================
I think the idea of supporting *MULTIPLE* "-expected-id" parameters is
a good thing.
(ie: an array of tap ids in the C code). It is a *SMALL* and reasonable
price to pay.
==================================
Here is the *SIMPLE* thing that needs to happen.
(1) There needs to be a new target event.
This event should happen when all taps have been "re-id" aka:
when the chain is validated.
Adding an event is really super easy.
target.h - there is an enum to add to
target.c - there is a Jim_Nvp to add to.
(2) At the end of the function: jtag_examine_chain() - you need to call
this function:
target_all_handle_event( YOUR_NEW_EVENT_ENUM );
(3) Lastly - there needs to be a single new TCL sub command.
We need a command that works like this:
Given a TAPNAME - what is the TAPID that was discovered?
For example:
set foo [jtag tapidof MYTAPNAME]
puts [format "The tap id is: 0x%08x" $foo]
To add the above see: "jtag.c" - function: 'jim_jtag_command()"
There is a table of sub commands.
There is a enumeration of commands.
And a switch statement to add the command into.
And an example is the "JTAG_CMD_ISENABLED"
Instead of returning 0/1 - you return the TAP ID.
================================================
Then, one could easily do this:
[which has a bug in it...but is easy to fix. keep reading...
$_TARGETNAME configure --event jtag-verify-tapid {
set tapname [$_TARGETNAME cget -chain-position]
# WHAT IS MISSING IS THIS COMMAND
# it takes the TAPNAME - and returns the TAPID.
set cur_tapid [ jtag tapidof $tapname ]
if { $cur_tapid == 0x12345678 } {
# GOOD TAP
return;
}
if { $cur_tapid == 0x87654321 } {
puts "**WARNING** THIS I NOT THE CHIP YOU ARE LOOKING FOR"
puts "You have the jumper configured wrong it will not
work in this config"
return;
}
puts [format "Unknown tap id 0x%08x - Maybe you have a new chip?"
$cur_tapid]
return;
}
So - what is the bug? In the above, in the eventbody ... it uses
"$_TARGETNAME" as the target name,
See: section 22.6.3 - BODY OR INLINE TEXT , item #1 in the description.
A 'hazard' one must be able to work around.
On a single target system - you will never find hit bug.
On a MULTIPLE GDB TARGET system - you would find this bug.
===================
Patches are welcome!
-Duane.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
