Øyvind Harboe wrote:
> On Tue, Jul 22, 2008 at 5:23 AM, Duane Ellis <[EMAIL PROTECTED]> wrote:
>
>> Duane Ellis wrote:
>>
>>> Øyvind Harboe wrote:
>>>
>>>> Would you be interested in porting target_process_reset to Tcl?
>>>>
>>>>
>>> Let me read through this code a bit and digest it.
>>>
>>>
>> I've done some reading - What I have to say will take a while to digest.
>> So think about it for a little bit - you might need to read this a few
>> times.
>>
>> To resolve the "process_reset" - I think we need to tackle some lower level
>> things first.
>>
>> For example - we need a "target" that is in TCL style first.
>>
>
> agreed.
>
> My biggest fear with the below is that we alienate existing users, so
> backwards compatibility is important.
>
>
Agreed.
>> This is important - because:
>>
>> The higher level scripts will need to invoke specific things on each target
>> in some order.
>>
>> Details follow:
>>
>> -Duane.
>>
>> =========
>> Background:
>> =========
>>
>> I'm not sure if you (or others) have done TK stuff - the graphics side of
>> TCL or not. Basically, in Tcl/TK when you create a "button" - you create a
>> new command that is specific to that button. In TK there are two ways of
>> creating a button:
>>
>> (1) Specifying lots of options all at once... when creating.
>>
>> button .foobar -background red -foreground green -font 10x20 -text
>> "Hi Mom"
>>
>> OR (2) - Creating the button, then modifying the button using the new
>> command.
>>
>> button .foobar [with no options]
>>
>> Which - creates a new command, in this case called ".foobar".
>>
>> Which you can "configure" as desired, for example:
>>
>> .foobar configure -background red -foreground green
>> .foobar configure -font 10x20 -text "Hi Mom"
>> .foobar -command { puts "Hi duane" }
>>
>> When we create a target, - like the button example above - we need to create
>> a new command for that target.
>>
>> =========
>> The New "target" command.
>> =========
>>
>> I propose a new "target" command - that works like the Tcl/TK button command
>> does.
>>
>> For compatibility reasons only...
>> if argv[0] = is a known target type, ie: "arm7tdmi" or "cortex_m3"
>> we assume all other parameters are positional.
>>
>> If the argv[0] is not a known target type, we do something else.
>> We demand it be one of these 4 things:
>>
>
> I'd like this to work for old targets as well, otherwise we'll have nothing
> to test against.
>
> Shouldn't be hard to detect options vs. positional parameters and convert
> positional parameters into options?
>
yes, simple to convert positional parameters.
>
>> (1) target create NAME [configure options]
>> [ as described above, sort of like 'button']
>>
>> (2) target delete NAME
>> [Destroys a target.]
>>
>> (3) target invoke NAME COMMAND
>> [see below, same as: "NAME COMMAND"]
>> (4) target list
>> [You use it like this:]
>>
>> proc poll_all_targets {
>> foreach T [ target list ] {
>> $T poll
>> }
>> }
>>
>
> cmd_ctx contains current target today. The above definitively moves
> current target out of cmd_ctx. OK by me, but we need backwards compatibility.
>
No it does not. The idea is the "command private" variable holds the
'current target pointer".
I do not see that something is breaking with the above.
>
>> ==========
>> TK Events - but OpenOCD events.
>> ==========
>>
>> TK has a command called "bind".
>>
>> You can use the BIND command to BIND X-window events to specific Tcl
>> Procedures.
>>
>> We need something similar -an- EVENT command.
>> {If you can suggest a better name... please do} it would work like this:
>>
>> eventcommand NAME -command "some command"
>>
>> Some ideas/examples would be:
>>
>> eventcommand gdbconnect -command "source gdb-connect-script"
>>
>> eventcommand prereset -command "DO SOMETHING..."
>>
>> Other names could be:
>>
>> gdbdisconnect
>> gdbstep
>> ... you name it ...
>>
>> This would roughly replace what is today: target_invoke_script()
>>
>
> Of course without breaking the target_script command. :-)
>
How do you think this would break the existing target script. I mean to
specifically *DELETE* the "target_X_NAME" support and no longer support
that at all.
Or is this something that needs to exist? I do not think so. It has had
less then 1month in the wild.
>
>> ==========
>> The key here is: "target invoke NAME COMMAND".
>> ==========
>>
>> there are two ways of invoking a TARGET command.
>> Option 1 -
>> target invoke NAME COMMAND
>>
>> Or Option 2
>> Because the 'target create' created a new command..
>> You can do this instead:
>>
>> NAME COMMAND
>>
>> ==========
>> This is important because:
>> ==========
>>
>> This lets higher level scripts invoke certain target specific function
>> calls.
>>
>> For example, STEP 1 - create target called "T_foobar".
>>
>> target create T_foobar -type arm7tdmi -endian little -chainpos 3 -varient
>> xyz
>>
>> We now have a "T_foobar" command we later can create these commands.
>> T_foobar halt
>> T_foobar step
>> T_foobar ... what ever ...
>>
>> For example - today the "mww" only works with the current target.
>>
>
> I consider the current target functionality of mww part of the Telnet
> user interface.
>
And "mww" will remain, a 1st class command - that effects the *CURRENT*
target. No intention of removing it. It should 100% stay there.
However, if you prefix "mww" with TARGETNAME - it effects only the
specified target and does not modify the current target.
In theory Sort of like this... - but not implemented like this.
push current target.
set target to NAME.
execute mww ADDRESS DATA
pop target
> almost *all* use of OpenOCD is single target, so we must not complicate the
> life of single target users.
>
Exactly - why "mww" and others will remain as 1st class commands, and
not become "subcommands".
The idea is PREFIX the command with the target name... and it is
target specific.
>
>> Yes, you *can* use the "targets" command to change targets - by number.
>>
>> But with the new idea - we can eventually can do this:
>>
>> T_foobar poke32 0x1234 0xdeadbeef
>> set VALUE [ T_foobar peek16 0x44432]
>>
>> Or
>> T_foobar step - which ONLY steps the target named T_foobar
>> T_foobar reg NAME VALUE
>>
>> ==========
>> What I need right now to redo process_reset is something like this:
>> ==========
>>
>> T_foobar reset assert [calls the assert reset]
>> T_foobar reset deassert [ calls the other function ]
>>
>
> looks OK to me.
>
>
>> The above "come along for free" - with this.
>>
>> ==========
>> I also need a "jtag" command of some sort.
>> ==========
>>
>> Specifically - i need something that lets me mess with or "enque" commands.
>> Or at least "execute the que".
>>
>> Today - there are many commands like:
>>
>> jtag_khz
>> jtag_nsrt_delay
>> .. and others ..
>>
>> There is nothing that does: jtag_execute_queue()
>>
>
> This needs a bit of thought:
>
> jtag_execute_queue() has a crucial feature: it tells you whether any
> of the commands
> in the queue failed.
>
Simple:
if { catch [jtag -execute-queue] msg } {
puts "ERROR: $msg"
}
> however, looking at drscan you see that if you make all tcl jtag
> commands return a
> value/scanned data, then you have to execute the queue before you return from
> the tcl api.
>
I need to read that part of the code. I have not been inside the
"drscan" and that type of stuff yet.
> I'm leaning towards *not* exposing jtag_execute_queue() and always return the
> data that was scanned.
>
> from C(high performance), you create large queues. High performance
> and tcl should
> not be mentioned in the same sentence :-)
>
>
>> ====
>> Thus, one can do this:
>> ====
>>
>> During the various "reset" steps. Events occur.
>> if an event procedure is defined for that event - it is invoked.
>>
>> In each of those events - a specific target command can occur.
>> One can now - define the "post-reset" event procedure to
>>
>> 1) Halt target FOO - because there is no other way.
>> 2) Set target FOO register: PC to 0xFFFF0000
>>
>> And other complicated things - like:
>> starting with a slow jtag speed.
>> Programing the clocks & sdram
>> Changing the jtag speed to fast
>>
>>
>>
>
> The above looks OK to me. I assume Jim supports all the features.
>
Yes, it should.
> My general comments is that we need to make sure that we don't alienate
> existing
> users and that things are backwards compatible. I don't think that
> will be too hard
> or be detrimental to the design.
>
>
Otherwise as some would say -- we would start another s__t storm.
-Duane.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
