Ø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 *
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
mem2array dataval 32 [expr
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
2009/5/5 Michel Catudal michelcatu...@gmail.com:
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
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 not in
Anders Montonen pisze:
It does, but not in an immediately obvious way:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-copy.html
I can do it that way, but the effect in a patch is worthless as I can
only create info about removal of the file, but the new file is not
created. In
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
On Sun, May 17, 2009 at 11:20 AM, Michael Bruck mbr...@digenius.de 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
-- 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
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
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
On Sun, May 17, 2009 at 3:49 PM, Duane Ellis open...@duaneellis.com 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
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
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
Ø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
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
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
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 use
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
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
Ø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
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
Ø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
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
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
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
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
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,
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);
-
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;
-
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 allocator?
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
On Sun, May 17, 2009 at 10:54 PM, Rick Altherr kc8...@kc8apf.net 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 =
On Sun, May 17, 2009 at 11:15 PM, David Brownell davi...@pacbell.net 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();
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 understand.
- 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
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
Xiaofan Chen a écrit :
2009/5/5 Michel Catudal michelcatu...@gmail.com:
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
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 thought
2009/5/18 Michel Catudal michelcatu...@gmail.com:
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
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 debug interfaces.
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 able
On Mon, May 18, 2009 at 8:58 AM, David Brownell davi...@pacbell.net 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
On Mon, May 18, 2009 at 10:06 AM, Strontium strnty...@gmail.com 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
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
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
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.
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
On May 17, 2009, at 1:14 PM, David Brownell wrote:
flash.patch___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Committed revision 1802.
--
Rick Altherr
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
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
On May 17, 2009, at 1:31 PM, David Brownell wrote:
mem.patch
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
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.
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
openocd-arm11-small-
fixes___
Openocd-development mailing list
2008/12/25 Michel Catudal michelcatu...@gmail.com:
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
55 matches
Mail list logo
