Putting my "user hat" on - I think we sort of went down the wrong path
with reset.
My reasoning and solution ideas follows.
-Duane.
============
Background:
Openocd is "part of a debugger" - it is not a board or program that runs
freely.
When something is under the control of a debugger - in some ways, I
liken "RESET" as "restart" - or "RESET" the mouse trap so I can find the
bug.
This implies to me - that (1) I can RESET the mouse trap - and (2) when
i am ready I tell the debugger to RUN or CONTINUE as the case may be.
This sort of implies that the default action in all cases should be:
To the best of your ability - RESET and halt at the reset vector.
Some targets - cannot do that - they do the best they can.
And can be made to act like that - simple proc.
GDB - on the host side has the same idea - it is sort of like "restart".
On Linux - this means: Kill and re-initialize the process space back to
the start condition.
Yes, on linux it also auto-executes the app - why? Because GDB _CAN_
initialize the target address space with a linux app.
Since it *CANNOT* always do this with an embedded target - it should
come damn close.
The issue is the "reset and run".
===
However, there are some complicating issues:
(A) Some targets you can do exactly that - with no consequences, no
complications.
ie: Reset, halt, at the reset vector.
Or - just simply halt and set the PC at the reset address
ie: A micro controller fits that example.
Others do not and get more complicated.
(B) Example: When you have an SDRAM present and you are loading the
program in SDRAM.
Example: AT91RM9200 - is a nasty beast.
If I reset the chip I must also:
Reprogram the Main OSC, Reprogram the PLLs, and re-initalize the
SDRAM.
Along the way - one must/can also change the jtag frequency.
In the past, I dealt with (B) by writing macros with the JTAG box I used.
===
Here is my observation and suggestion: I think we need to "divorce" two
things.
(a) wiggling the "hard reset signals"
(b) what the 'reset' command does.
I think "RESET" today - has become overloaded and complicated.
Step (1)
We create a new command - called: "hard_reset"
It means *WIGGLE* the pins like pressing a HARD reset button.
It should have some options. For example:
hard_reset configure -type <TYPE>
Where TYPE is one of run,halt,init, ... whatever
hard_reset cget
[displays current configuration]
hard_reset
[no options: does what ever is "configured" for all
targets]
hard_reset -target 3 -type foo
[performs type foo reset on target 3, does not
change configuration]
By default "hard_reset" does this and only this:
Wiggle JTAG pins and attempt to stop CPU @ reset vector.
Ready for the debugger to do what they want.
The HARD reset command performs *NO* actions
the HARD reset command has no "scripts" no nothing.
STEP 2
Delete the existing "reset" command - and replace it with
a new "reset" command that does this:
"hard_reset" with no options.
To change the configuration of "reset" you do this:
reset configure -command "SOME STRING"
To see the current configuration, use the standard "tcl" option "cget".
reset cget -command
Where: SOMESTRING defines what RESET does.
the default being: "hard_reset".
You can easily reconfigure "reset" like this:
Option (A) - The default is really this:
reset configure -action hard_reset
Option (B) [read commands from a file]
reset configure -command "source my_reset_file.txt"
Option (C) Execute a TCL function.
proc my_reset_function { } {
... pre-wiggle commands
# Wiggle the pins
hard_reset --target 0
... post-wiggle commands
}
reset configure -action my_reset_function
or reset configure -action "my_reset_function Param1 Parm2"
================
Options (B) and (C) address SPEN's issue:
>> Rather I'm thinking that a reset
>> procedure needs to be written
>> in script form to handle the
>> more contrived cases.
========================
This would also remove *ALL* of these "pre/post" reset things.
And all this "target_N_stuf"
I think this "pre/post" and event proc stuff is confusing the issue
to no end.
This is also some of what Tim Hudson is complaining about.
========================
I think this would also help address Tim Hudson's concern:
> What was there before was simple and easy to
> follow - and now you have to define two event
> procs to handle it - that does seem like a regression.
Why? Those event procs are gone.
And you can define "reset" to do what you want by
putting the commands you want _IN_ the script file
or in the TCL Proc - your choice.
========================
This answers Oyvinds concern:
>>- added hardcoded reset modes from gdb_server.c.
>> I don't know precisely what these defaults should be
>> or if it should be made configurable. Perhaps some
>> hardcoded defaults will do for now and it can be
>> made configurable later.
MAYBE - we define a new new command, that by default is this:
proc gdb_reset { } { reset }
A RESET request from GDB (not "mon reset") executes: "gdb_reset"
By default - it ends up executing "reset" - however:
Thus, if the user needs to "monkey" with RESET because of GDB... the
user can.
For example - it could reset the board and reconfigure the SDRAM ...
In the *SAME* simple 3 ways described above.
========================
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
