Re: [Openocd-development] [patch] fix typo in smdk6431

[Rick Altherr]

On Dec 10, 2008, at 6:36 PM, Duane Ellis wrote:

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.

Ok.

==================================

Here is the *SIMPLE* thing that needs to happen.

(1) There needs to be a new target event.

     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.

This event should happen when all taps have been "re-id" aka: when the chain is validated.

I don't think the target is the right place for this. 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? For other reasons related to enabling/disabling taps, I think we need to introduce jtag events. These events seem to be the correct place for ID checking.

(2) At the end of the function: jtag_examine_chain() - you need to call this function:

           target_all_handle_event(   YOUR_NEW_EVENT_ENUM );

Would become jtag_tap_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.

This would be a useful addition for many purposes.

================================================

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 } {

              return;
    }


    return;
}


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.

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" puts [format "Unknown tap id 0x%08x - Maybe you have a new chip?" $cur_tapid] 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.

This would be almost the same except that it would be configuring the event on the tap and the tapname would already be known.

===================

Patches are welcome!

-Duane.

--
Rick Altherr
[EMAIL PROTECTED]


 -- Unsigned

"He said he hadn't had a byte in three days. I had a short, so I split it with him."

smime.p7s
Description: S/MIME cryptographic signature

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