Re: [Openocd-development] TCL unkown ocd_mem2array
Øyvind Harboe wrote: You have to create the target before the init command. One could talk about allowing targets to be created/deleted on the fly, but OpenOCD isn't at that stage today. This works: openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg -c target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu -c init -c ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 Move init and it fails: openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg -c init -c target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu -c ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 Hmm, ok, on the command line this seems to be the difference. Any idea what might be different doing it at (telnet) command prompt: -- cut -- openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg Open On-Chip Debugger targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- init target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- 0: omap3.cpu cortex_m3 little 0 omap3.cpu unknown ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 invalid command name ocd_mem2array_dataval called at file command.c, line 453 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 -- cut -- vs. -- cut -- openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg Open On-Chip Debugger targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- 0: omap3.cpu cortex_m3 little 0 omap3.cpu unknown init ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 invalid command name ocd_mem2array_dataval called at file command.c, line 453 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 -- cut -- ? Independent of init and target create order, both give the same result: Failing ocd_mem2array. Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
You can't use target create on the telnet command line because it is after init. If init is not on the command line, OpenOCD runs it before launching the telnet server. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Øyvind Harboe wrote: You can't use target create on the telnet command line because it is after init. If init is not on the command line, OpenOCD runs it before launching the telnet server. Ah, that explains a lot! ;) Will try it. Thanks Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
On Mon, May 18, 2009 at 7:55 PM, Dirk Behme dirk.be...@googlemail.com wrote: Ųyvind Harboe wrote: You can't use target create on the telnet command line because it is after init. If init is not on the command line, OpenOCD runs it before launching the telnet server. Ah, that explains a lot! ;) Will try it. Any thoughts on how OpenOCD could be made clearer at this point? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Øyvind Harboe wrote: On Mon, May 18, 2009 at 7:55 PM, Dirk Behme dirk.be...@googlemail.com wrote: Ųyvind Harboe wrote: You can't use target create on the telnet command line because it is after init. If init is not on the command line, OpenOCD runs it before launching the telnet server. Ah, that explains a lot! ;) Will try it. Any thoughts on how OpenOCD could be made clearer at this point? Some additional printfs and/or error messages? E.g. - When init is executed 'automatically' at startup: printf(Info: init successfully done\n); - When you try to do init again if it is already done once: printf(Error: System already initialized\n); - If you try to execute target create after init: printf(Error: Can't create target after initialization\n) Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Zach Welch wrote: On Sun, 2009-05-10 at 22:31 +0200, Magnus Lundin wrote: So some progress, but nothing more ;) (all: Above error is from TCL script containing ocd_mem2array romtable_cid 32 [expr ($debugbase0xF000) + 0xFF0] 4) Do you have any special patches or do I need any special configure option to enable ( compile) tclapi.c? Standard build, nothing special, sometimes an extra (perhaps unneccessary) round of automake make clean ./configure --enable-jlink --enable-ft2232_libftdi --enable-maintainer-mode--enable-parport make As already mentioned, looking into the code: ocd_mem2array is registered in tclapi_register_commands() in tclapi.c. But: It seems to me that tclapi_register_commands() isn't called anywhere, and even worse, tclapi.c isn't compiled. I even can't find it in any ocd_mem2array is also registered in target.c : target_register_user_commands, line 1302 in head I really suspect that tclapi.c is redundant, but I dont know D'oh. I should have done some more research on my own, but I figured it was safer to bet that I was premature to remove it. But sure enough, your discovery made me look around, and tclapi.c appears to be entirely redundant at this point: ocd_mem2array and ocd_array2mem are in target.c ocd_flash_banks is in flash.c drscan is in jtag.c. So... I was originally correct to remove it, and I have now done so again because I think that it just introduced a substantial regression. The patch has effectively been reversed in r1694. Sorry for the noise. The irony is that I nuked tclapi.c to eliminate possible confusion! It seems that Strontium's mem2array issue is fixed with Øyvind's patch (see previous mail), now :) But seems that my issue isn't :( To remember, my issue was and is that I can't execute 'ocd_mem2array'. r1800 (with Øyvind's patch) gives me -- cut -- version Open On-Chip Debugger 0.2.0-in-development (2009-05-17-07:51) svn:1800 omap3.cpu mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 invalid command name ocd_mem2array_dataval called at file command.c, line 453 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 -- cut -- Most probably I do some stupid thing wrong here, but I can't see it at the moment :( Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
-- cut -- version Open On-Chip Debugger 0.2.0-in-development (2009-05-17-07:51) svn:1800 omap3.cpu mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 invalid command name ocd_mem2array_dataval called at file command.c, line 453 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 -- cut -- Most probably I do some stupid thing wrong here, but I can't see it at the moment :( Try w/svn head. Seems to work fine here: Open On-Chip Debugger ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 Target not examined yet mem2array: Read @ 0x54011000, w=4, cnt=1, failed targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- 0: at91eb40a.cpu arm7tdmi little 0 at91eb40a.cpu unknown at91eb40a.cpu mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 Target not examined yet mem2array: Read @ 0x54011000, w=4, cnt=1, failed -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 FYI - I wrote the original JimTCL memory functions here last year, sadly my documentation level sort of sucks eh? The intent was to *NEVER* really expose ocd_mem2array that was a builder function. Based on my quick read of what you are doing you should source the file memory.tcl or mmr_helpers.tcl Do this in your CONFIGURE script: source [find tcl/memory.tcl] That file has a number of functions like: memread32 ADDRESS By design, it handles various errors. You might also take a look around find the files: stm32_regs.tcl - and some sam7 versions. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Strange indeed. Parsing works here... ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 Target not examined yet mem2array: Read @ 0x54011000, w=4, cnt=1, failed -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Øyvind Harboe wrote: Strange indeed. Parsing works here... Yes, I believe this ;) The big question is what might be different for me. From your last mail, you use 'at91eb40a' CPU configuration? Maybe the init scripts for this do some magic which is missing for me? What scripts do you source for this, just to have a look. Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
On Sunday 17 May 2009, Duane Ellis wrote:
FYI - I wrote the original JimTCL memory functions here last year, sadly
my documentation level sort of sucks eh?
Documentation? Didn't even know that tcl/* stuff existed. :)
There aren't even any users of the tcl/* stuff in any of
the existing cfg files. And as we know, examples are all
too often substitutes for documentation.
The intent was to *NEVER* really expose ocd_mem2array that was a
builder function. Based on my quick read of what you are doing you
should source the file memory.tcl or mmr_helpers.tcl
Do this in your CONFIGURE script:
source [find tcl/memory.tcl]
That file has a number of functions like: memread32 ADDRESS
Hmm, I asked about this sort of thing not long ago:
https://lists.berlios.de/pipermail/openocd-development/2009-May/006340.html
Nobody knew about memread32 as an answer...
By design, it handles various errors.
Everyone seems to be using mw{b,h,w} instead of memwrite{8,16,32}
and I was the first to seem to notice that the md{b,h,w} siblings
were useless for scripting purposes.
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).
These seem like the sorts of things that ought to be builtins,
not library layers...
You might also take a look around find the files: stm32_regs.tcl -
and some sam7 versions.
Hmm, I noticed that chip/atmel/at91/at91sam7x128.tcl (for example)
defines a global AT91C_ID ... which strongly presumes that there's
only one at91 family chip, since those IDs vary between chips.
What I had started to do with some DaVinci stuff is define a
dictionary with various chip-specific symbols, then have the
utlities use the relevant dictionary.
Now, I *like* the idea of having a way to grow libraries of
reusable Jim code to help work with chips, and symbolic names
for registers (or at least controllers) seems essential to that.
But I'm not sure that's quite the right way to start.
- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
On Sun, May 17, 2009 at 8:02 PM, Dirk Behme dirk.be...@googlemail.com wrote: Ųyvind Harboe wrote: Strange indeed. Parsing works here... Yes, I believe this ;) The big question is what might be different for me. From your last mail, you use 'at91eb40a' CPU configuration? Maybe the init scripts for this do some magic which is missing for me? What scripts do you source for this, just to have a loo Try the command line below to replicate my setup: openocd -f interface/dummy.cfg -f target/at91eb40a.cfg (using configure --enable-dummy to build the dummy driver...) -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
For reference, this little utility:
# mrw: memory read word, returns value of $reg
proc mrw {reg} {
set value
ocd_mem2array value 32 $reg 1
return $value(0)
}
works fine in my tree, which is still at r1793.
... and yes, I'd be all for removing that hack which
morphs cmd arg1 arg2 ... into cmd_arg1 on typo.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
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)
daviddefines 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
Re: [Openocd-development] TCL unkown ocd_mem2array
Øyvind Harboe wrote: On Sun, May 17, 2009 at 8:02 PM, Dirk Behme dirk.be...@googlemail.com wrote: Ųyvind Harboe wrote: Strange indeed. Parsing works here... Yes, I believe this ;) The big question is what might be different for me. From your last mail, you use 'at91eb40a' CPU configuration? Maybe the init scripts for this do some magic which is missing for me? What scripts do you source for this, just to have a loo Try the command line below to replicate my setup: openocd -f interface/dummy.cfg -f target/at91eb40a.cfg (using configure --enable-dummy to build the dummy driver...) Done: version Open On-Chip Debugger 0.2.0-in-development (2009-05-17-20:48) svn:1801 targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- 0: at91eb40a.cpu arm7tdmi little 0 at91eb40a.cpu unknown ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 Target not examined yet mem2array: Read @ 0x54011000, w=4, cnt=1, failed So this *does* work :) Looks like a Cortex configuration/environment issue then. Thanks Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
So this *does* work :) Looks like a Cortex configuration/environment issue then. Strange indeed. Can you reproduce it w/your target and the dummy driver? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
Øyvind Harboe wrote: So this *does* work :) Looks like a Cortex configuration/environment issue then. Strange indeed. Can you reproduce it w/your target and the dummy driver? openocd -s lib/openocd/ -f interface/dummy.cfg -f board/ti_beagleboard.cfg version Open On-Chip Debugger 0.2.0-in-development (2009-05-17-20:48) svn:1801 target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- 0: omap3.cpu cortex_m3 little 0 omap3.cpu unknown ocd_mem2array dataval 32 [expr 0x54011000 + 0 * 4] 1 invalid command name ocd_mem2array_dataval called at file command.c, line 453 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 For your reference: ti_beagleboard.cfg is in svn: ./src/target/board/ti_beagleboard.cfg Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
You have to create the target before the init command. One could talk about allowing targets to be created/deleted on the fly, but OpenOCD isn't at that stage today. This works: openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg -c target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu -c init -c ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 Move init and it fails: openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg -c init -c target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu -c ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
On Sunday 17 May 2009, Duane Ellis wrote: david Hmm, I noticed that chip/atmel/at91/at91sam7x128.tcl (for example) daviddefines 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. Right, but AT91C_ID is a good example of how Atmel changes things between parts. Those IDs are used in two controller-specific ways: defining IRQ lines, and gating clocks (for clocks that can be gated). So when one part may have four UARTs, another may have just two but will add a CAN controller; those IDs will then mean different things. Compare that sam7 part with any of the sam9 parts, for example, or an rm9200. You're correct that those individual controllers haven't tended to vary much. (The AVR32 parts use pretty much the same designs.) That's software-friendly, but not all hardware houses work like that. And in newer designs, Atmel has had to evolve some of their more fundamental things ... running out of pinmux options and module IDs for more complex chips will do that. 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. And accept that what seems constant for now may well change soon, for most vendors. The next chip iteration is likely to differ in more than just the amount of memory or clock speed. That understanding develops over time, and is encapsulated in code that handles more and more of the family. A dictionary does OK for handling this controller is at a different address differences, and can help address other types of differences. Mostly I see it as a way to structure things ... there may be better ones. Globals won't work. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array, was: dap command for OMAP and tcl scripting
On Sun, 2009-05-10 at 15:20 +0200, Dirk Behme wrote: [snip] As already mentioned, looking into the code: ocd_mem2array is registered in tclapi_register_commands() in tclapi.c. But: It seems to me that tclapi_register_commands() isn't called anywhere, and even worse, tclapi.c isn't compiled. I even can't find it in any Makefile. I just recently removed this file from the trunk, because -- as you said -- it was not being compiled. Now it sounds like that might have been a mistake, so I tried to pull it back and make it part of the build. In doing so, I continue to wonder if there perhaps was a reason it was not being maintained. It did not compile without a patch, and further fixes may be needed to build it on all platforms (or to fix bit rot that only appears at run-time). Committed in r1691. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array, was: dap command for OMAP and tcl scripting
So some progress, but nothing more ;) (all: Above error is from TCL script containing ocd_mem2array romtable_cid 32 [expr ($debugbase0xF000) + 0xFF0] 4) Do you have any special patches or do I need any special configure option to enable ( compile) tclapi.c? Standard build, nothing special, sometimes an extra (perhaps unneccessary) round of automake make clean ./configure --enable-jlink --enable-ft2232_libftdi --enable-maintainer-mode--enable-parport make As already mentioned, looking into the code: ocd_mem2array is registered in tclapi_register_commands() in tclapi.c. But: It seems to me that tclapi_register_commands() isn't called anywhere, and even worse, tclapi.c isn't compiled. I even can't find it in any ocd_mem2array is also registered in target.c : target_register_user_commands, line 1302 in head I really suspect that tclapi.c is redundant, but I dont know Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array, was: dap command for OMAP and tcl scripting
On Sun, 2009-05-10 at 22:31 +0200, Magnus Lundin wrote: So some progress, but nothing more ;) (all: Above error is from TCL script containing ocd_mem2array romtable_cid 32 [expr ($debugbase0xF000) + 0xFF0] 4) Do you have any special patches or do I need any special configure option to enable ( compile) tclapi.c? Standard build, nothing special, sometimes an extra (perhaps unneccessary) round of automake make clean ./configure --enable-jlink --enable-ft2232_libftdi --enable-maintainer-mode--enable-parport make As already mentioned, looking into the code: ocd_mem2array is registered in tclapi_register_commands() in tclapi.c. But: It seems to me that tclapi_register_commands() isn't called anywhere, and even worse, tclapi.c isn't compiled. I even can't find it in any ocd_mem2array is also registered in target.c : target_register_user_commands, line 1302 in head I really suspect that tclapi.c is redundant, but I dont know D'oh. I should have done some more research on my own, but I figured it was safer to bet that I was premature to remove it. But sure enough, your discovery made me look around, and tclapi.c appears to be entirely redundant at this point: ocd_mem2array and ocd_array2mem are in target.c ocd_flash_banks is in flash.c drscan is in jtag.c. So... I was originally correct to remove it, and I have now done so again because I think that it just introduced a substantial regression. The patch has effectively been reversed in r1694. Sorry for the noise. The irony is that I nuked tclapi.c to eliminate possible confusion! Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
