duane> [about stuff in tcl/memory.tcl]
david> Hmm, I asked about this sort of thing not long ago:
I've been buried with other tasks and not paying attention much on the
list for a while.. Other things had to take priorities.
david> Everyone seems to be using mw{b,h,w} instead of memwrite{8,16,32}
Yea, the problem comes down to this:
There are the "old command context" based commands
ie: The original way Dominic et al wrote OpenOCD - which are PRE
JimTCL.
And there are the new "tcl" based commands.
Which was introduced mid last year
Not everything has been transitioned.
The MW{BHW} should really be *removed* - in fact all "command context"
commands should be deprecated and removed/replaced.
The problem is "hurding cats" every cat has their own solution, and
every cat thinks *some*other* part (ie: their part) of OpenOCD is more
important to work on, people get mad... upset, and angry :-(
> There are also various arm-specific utilities, some to work with
> physical addressese (vs, I guess, "whatever the current MMU context
> or non-context delivers").
>
Yes, and those commands effect the *current* target (as defined by a
global variable in OpenOCD) nobody has really had multiple targets yet
that I am aware of, I'm sure there that when somebody has a *REAL* dual
core target system things will become very very interesting and lots of
bugs will come out.
When I created the "target-as-an-object" command system last year, ie:
the "omap.cpu" command creation, I specifically addressed that - so that
one *COULD* in theory read/write specific targets.
What is *REALLY* missing in terms of documentation is "road map"
material - intent of certain things, methods, etc. So that people see a
vision of how things can come together to solve a problem.
ie: Why does the the HTTP server exist and the TCL server exist? It's
not what people think. The intent is/was a universal GUI front end, and
the ability to script OpenOCD in a far more universal way then anything
one might do with a "libopenocd" solution and is *DIRECTLY* related to
the "chip.tcl" stuff.
BTW - I wrote all of that TCL stuff nearly 9 months ago.
david> Hmm, I noticed that chip/atmel/at91/at91sam7x128.tcl (for example)
david>defines a global AT91C_ID ... which strongly presumes that there's
david> only one at91 family chip, since those IDs vary between chips.
In general, atmel has a single set of IP that defines a peripherals, and
they re-use it over and over again across all of the AT91 series parts,
sort of like a "we have a uart in our chip library". Other chip
companies do the same thing. All atmel uarts have the same flavor - they
have one uart design - and it has evolved over the years.
david> What I had started to do with some DaVinci stuff is define a
david> dictionary with various chip-specific symbols, then have the
david> utilities use the relevant dictionary.
Good idea! The real trick is to understand how the family goes together.
You also might look a the other top level things in the top level directory.
-Duane.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
