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.
>
> 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?
> (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.
>
> ==========
> 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. :-)
> ==========
> 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.
almost *all* use of OpenOCD is single target, so we must not complicate the
life of single target users.
> 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.
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'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.
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.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
