[Openocd-development] arm7_9_common.c Documentation Updates

Hey all, This is a patch that adds some function block Doxygen comments for a number of the functions in arm7_9_command.c. I'm trying to keep the patches small so that those who know the functions well don't have a lot to read all of the time. Besides, I have to learn what the functions do

[Openocd-development] OpenOCD and different versions of J-Link

2008/12/25 Michel Catudal : > I could not get my older black j-link devices to work while the newer yellow > one works. I am curious as to what the basic difference would be between > the two. I tested them at work and they were working just as good on windows > as the yellow one with IAR 5.2. (I d

Re: [Openocd-development] [PATCH] ARM11 cleanup stale dependencies with generic arm code; added comments and whitespace fixes

On May 17, 2009, at 2:40 PM, Michael Bruck wrote: - remove stale interdepencies between arm11 and arm7_9_common - added comments - fixed some indentation Michael fixes>___ Openocd-development mailing list Openocd-development@lists.berlios.de https:

Re: [Openocd-development] [patch] doc -- working area

On May 17, 2009, at 2:16 PM, David Brownell wrote: Move description of the working area setup from the description of the old deprecated syntax to go with $TARGET configure calls. Mention that the ARM DCC download support needs working area. ___ Ope

Re: [Openocd-development] [patch] doc: arm7_9 fast_memory_access

On May 17, 2009, at 1:31 PM, David Brownell wrote: Committed revision 1805. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___

Re: [Openocd-development] [patch] accept target *names* everywhere, not just numbers

On May 17, 2009, at 1:18 PM, David Brownell wrote: Replace get_target_by_num() with get_target(): - Allows target names, not just numbers ... numbers are awkward for config scripts, given for example a system with several CPUs or flash chips. - Slightly shrinks most call sites by removing

Re: [Openocd-development] [patch] doc: mention ETM and ETB (for ARM)

On May 17, 2009, at 1:29 PM, David Brownell wrote: Doc should at least mention the ETM and ETB support found on some ARM chips. Also include a convention about naming the ETB tap. NOTE that (a) I suspect this isn't widely used yet, even though it's kind of neat, and (b) in some cases the ETM

Re: [Openocd-development] [patch] whitespace cleanup for src/flash/*nand*

On May 17, 2009, at 1:14 PM, David Brownell wrote: ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Committed revision 1802. -- Rick Altherr kc8...@kc8apf.net

Re: [Openocd-development] JTAG, FT2232 and JLink

On May 17, 2009, at 9:03 PM, David Brownell wrote: On Friday 15 May 2009, Øyvind Harboe wrote: So apply this patch? Can anyone test? jtagpatch.txt It failed for me on an ft2232 device. Hmm. It looks like the jtag.c changes turn on the new "short sequence" table for FT2232 and JLink

Re: [Openocd-development] openocd & c99 - and the compiler

On May 17, 2009, at 6:16 PM, Duane Ellis wrote: I have an observation I'd like to confirm: I missed the earlier email traffic about "c99" etc - and all that sort of stuff. In all cases is is my belief that the *ONLY* compiler that is used to build OpenOCD is GCC, and nothing but GCC, period.

Re: [Openocd-development] PIC32 openocd status

> > This is wrong. ICSP is Microchip's proprietory protocol for > programming and debugging. The ICSP module is independent > from the EJTAG module in PIC32. You can read Chapter > 33 of the PIC32MX Family Manual for more information. I didn't make it up. I read it. PIC32MX Flash Programming Spe

Re: [Openocd-development] JTAG, FT2232 and JLink

On Friday 15 May 2009, Øyvind Harboe wrote: > So apply this patch? > > Can anyone test? > > jtagpatch.txt It failed for me on an ft2232 device. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/

Re: [Openocd-development] PIC32 openocd status

On Mon, May 18, 2009 at 10:06 AM, Strontium wrote: >> >> This is wrong. ICSP is Microchip's proprietory protocol for >> programming and debugging. The ICSP module is independent >> from the EJTAG module in PIC32. You can read Chapter >> 33 of the PIC32MX Family Manual for more information. > > I d

[Openocd-development] AT91SAM7X256 Flash and verify_image

Hey all, I've been playing a bit with my AT91SAM7X-EK (AT91SAM7X256) development board from Atmel and doing the whole flash, verify, run dance. It seems that the verify image may be a bit broken. For some reason, it keeps kicking the target into the run mode when I tell it to verify. By the

Re: [Openocd-development] PIC32 openocd status

On Mon, May 18, 2009 at 8:58 AM, David Brownell wrote: > On Sunday 17 May 2009, Strontium wrote: >> >> Pic32 has 2 debug interfaces.  4 Wire JTAG.  And a pin count compressed >> version of Jtag which is serialised over 2 wires (ICSP).  The protocol >> is the same as JTAG, the electrical interface

[Openocd-development] openocd & c99 - and the compiler

I have an observation I'd like to confirm: I missed the earlier email traffic about "c99" etc - and all that sort of stuff. In all cases is is my belief that the *ONLY* compiler that is used to build OpenOCD is GCC, and nothing but GCC, period. I suspect GCC is of some recent vintage - ie: 3.4

Re: [Openocd-development] PIC32 openocd status

On Sunday 17 May 2009, Strontium wrote: > > Pic32 has 2 debug interfaces.  4 Wire JTAG.  And a pin count compressed > version of Jtag which is serialised over 2 wires (ICSP).  The protocol > is the same as JTAG, the electrical interface is the only thing that > differs. 2 wire mode should be ab

Re: [Openocd-development] PIC32 openocd status

> >> It would be great that openocd can work with >> PIC32 using JTAG. I think Real ICE, ICD 2 and >> ICD 3 do not use JTAG for debugging PIC32. >> >> >> > I am aware of that, that is why I think that it would be easier for > debugging when we get PIC32 supported. > > Pic32 has 2 deb

Re: [Openocd-development] PIC32 openocd status

2009/5/18 Michel Catudal : >> For programming, you can probably use the US$35 >> PICkit 2 and pk2cmd. But there is no debugging >> support with PICkit 2 for PIC32. pk2cmd's source >> codes are also available. >> http://www.microchip.com/pickit2 >> > I saw that and may purchase it if there is suppor

[Openocd-development] NAND documentation? My current notes...

The following are some notes I put together about the "nand" commands based on reading the source code. I plan to turn them into documentation sometime later, maybe by this time next week. I've seen no documentation on the NAND commands; that seems like a significant omission. Meanwhile I though

Re: [Openocd-development] PIC32 openocd status

Xiaofan Chen a écrit : > 2009/5/5 Michel Catudal : > >> A project I am working on is to make a programmer for the PIC32 on SuSE >> Linux. I am looking into implementing the use of the Programming >> Excecutive in OpenOCD. >> I have read the documentation from Microchip and it seems straight >> f

Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code

On May 17, 2009, at 2:17 PM, Michael Bruck wrote: ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Rather than combine them, I'd like to see jtag_queue_command()

[Openocd-development] [PATCH] ARM11 cleanup stale dependencies with generic arm code; added comments and whitespace fixes

- remove stale interdepencies between arm11 and arm7_9_common - added comments - fixed some indentation Michael openocd-arm11-small-fixes Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.

Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code

On Sunday 17 May 2009, Michael Bruck wrote: > I did not primarily want to compact code but separate layers. The > function wraps the queue manipulation. The data structure > initialization itself is much more code than just the type field so I > don't like the idea of tearing it apart. I understan

Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code

On Sun, May 17, 2009 at 11:15 PM, David Brownell wrote: > On Sunday 17 May 2009, Rick Altherr wrote: >> Rather than combine them, I'd like to see jtag_queue_command() enforce >> validation of the command to be enqueued.  Then the patterns would be: >> >> cmd = cmd_queue_alloc(); >> >> cmd->type =

Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code

On Sun, May 17, 2009 at 10:54 PM, Rick Altherr wrote: > > On May 17, 2009, at 1:43 PM, David Brownell wrote: > >> On Sunday 17 May 2009, Michael Bruck wrote: >>> >>> -       jtag_command_t **last_cmd; >>> -       last_cmd = jtag_get_last_command_p(); >>> - >>> -       *last_cmd = cmd_queue_alloc(s

[Openocd-development] [patch] doc -- working area

Move description of the working area setup from the description of the old deprecated syntax to go with $TARGET configure calls. Mention that the ARM DCC download support needs working area. Move description of the working area setup from the description of the old deprecated syntax to go with $T

Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code

On Sunday 17 May 2009, Rick Altherr wrote: > Rather than combine them, I'd like to see jtag_queue_command() enforce   > validation of the command to be enqueued.  Then the patterns would be: > > cmd = cmd_queue_alloc(); > > cmd->type = JTAG_SCAN; > Then how about passing JTAG_* to the alloc

Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code

On May 17, 2009, at 1:43 PM, David Brownell wrote: On Sunday 17 May 2009, Michael Bruck wrote: - jtag_command_t **last_cmd; - last_cmd = jtag_get_last_command_p(); - - *last_cmd = cmd_queue_alloc(sizeof(jtag_command_t)); - (*last_cmd)->next = NULL; - last_comand_p

Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code

On Sunday 17 May 2009, Michael Bruck wrote: > -   jtag_command_t **last_cmd; > -   last_cmd = jtag_get_last_command_p(); > - > -   *last_cmd = cmd_queue_alloc(sizeof(jtag_command_t)); > -   (*last_cmd)->next = NULL; > -   last_comand_pointer = &((*last_cmd)->next); > -   (*l

[Openocd-development] [patch] doc: arm7_9 fast_memory_access

It's the faster mode that's potentially less safe, not the slower one. --- a/src/target/arm7_9_common.c +++ b/src/target/arm7_9_common.c @@ -2591,7 +2591,7 @@ int arm7_9_register_commands(struct command_context_s *cmd_ctx) register_command(cmd_ctx, arm7_9_cmd, "dbgrq", handle_arm7_9_dbgrq_command

[Openocd-development] [patch] accept target *names* everywhere, not just numbers

Replace get_target_by_num() with get_target(): - Allows target names, not just numbers ... numbers are awkward for config scripts, given for example a system with several CPUs or flash chips. - Slightly shrinks most call sites by removing strtoul() calls. - Use the same error message e

[Openocd-development] [patch] doc: mention ETM and ETB (for ARM)

Doc should at least mention the ETM and ETB support found on some ARM chips. Also include a convention about naming the ETB tap. NOTE that (a) I suspect this isn't widely used yet, even though it's kind of neat, and (b) in some cases the ETM parameters can be detected from a module query, so it's

[Openocd-development] [patch] whitespace cleanup for src/flash/*nand*

Misc whitespace fixes in src/flash directory, for NAND. Plus a couple minor spelling fixes. --- src/flash/lpc3180_nand_controller.c | 260 +-- src/flash/nand.c| 320 +- src/flash/nand.h| 28 +- src

Re: [Openocd-development] [Tiff] Potential problem in libtiff when compiled in MinGW

>> Since MinGW uses older msvcrt.dll which is unlikely to be updated >> (API-wise), that situation will probably remain. > > Switching to a more conformant printf utility sounds good then. > The Linux one is nice.  ;) I just hate the idea of trying to map out all the quirks of an older printf() th

Re: [Openocd-development] [Tiff] Potential problem in libtiff when compiled in MinGW

On Sunday 17 May 2009, Igor Skochinsky wrote: > None of the MSVC runtime libraries support %ll, you have to use %I64. Let's hear it for Microsoft's conformance to standard!!! (sound of crickets chirping...) > Since MinGW uses older msvcrt.dll which is unlikely to be updated > (API-wise), tha

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) > 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 singl

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 l

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 Debu

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 __

Re: [Openocd-development] TCL unkown ocd_mem2array

Øyvind Harboe wrote: > On Sun, May 17, 2009 at 8:02 PM, Dirk Behme 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 th

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,

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

Re: [Openocd-development] [Tiff] Potential problem in libtiff when compiled in MinGW

Hello Bob, Sunday, May 17, 2009, 6:44:41 PM, you wrote: BF> I see. MinGW depends on whatever library happens to be installed so BF> %ll may work on some Windows systems (which happen to have an BF> updated library) and not on others. None of the MSVC runtime libraries support %ll, you have to u

Re: [Openocd-development] TCL unkown ocd_mem2array

On Sun, May 17, 2009 at 8:02 PM, Dirk Behme 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

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

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

Re: [Openocd-development] [PATCH] change ir_scan to bool

A common way of handling these types of format-string differences for 32/64 bit cases is to define macros named things like PRIX32 which expands to the proper % sequence to print a 32-bit number as hex. We could do something similar for size_t and introduce something like PRIuSIZE. For an

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 __

Re: [Openocd-development] TCL unkown ocd_mem2array

Øyvind Harboe wrote: >> -- 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" >

Re: [Openocd-development] Command name combining with underscores

On Sun, May 17, 2009 at 3:49 PM, Duane Ellis wrote: > All, > > Last year (I think it was mid July) when JimTCL was originally being > introduced to OpenOCD, we wanted to have some means to make the > transition from "old commands to new commands" - work easily. > > At the time we made a collective

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

[Openocd-development] Command name combining with underscores

All, Last year (I think it was mid July) when JimTCL was originally being introduced to OpenOCD, we wanted to have some means to make the transition from "old commands to new commands" - work easily. At the time we made a collective decision to handle errors like this: Example command lin

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"

Re: [Openocd-development] [PATCH] change ir_scan to bool

On Sun, May 17, 2009 at 11:20 AM, Michael Bruck wrote: > At least the arm11 port has a macro ZU that is intended to be used > when size_t is printed. I recently saw a patch that ignored that, but > I didn't comment on this error because it is like fighting windmills. > Someone who regularly compil

Re: [Openocd-development] mem2array/array2mem fixes

I've committed the fix. Though there are actually 4 test cases and I only smoketested them + we have no regression test library. :-) ocd_mem2array xxx omap3.cpu mem2array xxx array2mem xxx omap3.cpu array2mem xxx -- Øyvind Harboe Embedded software and hardware consulting services http://cons

Re: [Openocd-development] resubmit lost works!

Anders Montonen pisze: > It does, but not in an immediately obvious way: >

Re: [Openocd-development] resubmit lost works!

On May 17, 2009, at 11:06, Freddie Chopin wrote: > Zach Welch pisze: >> They should have been treated to 'svn mv', because this would have >> preserved the history available from 'svn log'. > First of all - I've tied to do that this way, but TortoiseSVN does not > offer such option. It does, but n

[Openocd-development] PIC32 openocd status

2009/5/5 Michel Catudal : > A project I am working on is to make a programmer for the PIC32 on SuSE > Linux. I am looking into implementing the use of the Programming > Excecutive in OpenOCD. > I have read the documentation from Microchip and it seems straight > forward, the OpenOCD implementation

Re: [Openocd-development] [PATCH] change ir_scan to bool

At least the arm11 port has a macro ZU that is intended to be used when size_t is printed. I recently saw a patch that ignored that, but I didn't comment on this error because it is like fighting windmills. Someone who regularly compiles mingw (or a cross-compile farm) would be in a better position

[Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code

The code in jtag.c currently manipulates the command queue pointers directly in every function. This increases potential for errors and makes the code less readable by distracting the reader from the core algorithm contained in every function. This patch removes the (repetitive) direct command que

Re: [Openocd-development] resubmit lost works!

Zach Welch pisze: > They should have been treated to 'svn mv', because this would have > preserved the history available from 'svn log'. First of all - I've tied to do that this way, but TortoiseSVN does not offer such option. Second of all - these are just config files and their history holds

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 ($debugbase&0xF000) + 0xFF0] 4") >>> >>> Do you have any special patches or do

Re: [Openocd-development] mem2array - i cant get it to work :(

Strontium wrote: > Magnus Lundin wrote: >> Magnus Lundin wrote: >> >>> When I do this for the Beagle i just use >>> >>> # set the current target, should not be nexessary with only one target >>> configured >>> targets omap3.cpu >>> # call tcl functions without the extra target name >>> mem2arr

Re: [Openocd-development] mem2array/array2mem fixes

Øyvind Harboe wrote: > Please test this patch to see if it fixes mem2array/array2mem. This seems to fix Strontium's issue. Unpatched r1800 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