On Monday 15 June 2009 20:55:00 Freddie Chopin wrote:
> Michael Schwingen pisze:
> > those poor windows-only users
>
> I think that majority of OpenOCD users are on Windows... Yes, they are
> not as l33t as the Linux users, but still...
>
> http://developer.berlios.de/project/showfiles.php?group_id
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Zach Welch
> Sent: dinsdag 16 juni 2009 1:19
> To: open...@duaneellis.com
> Cc: Openocd-Dev
> Subject: Re: [Openocd-development] Nit to pick with r
Dear all:
When setting bp in opocd, there are 2 options I am concerned with,
length and hw.
What do they mean?
appreciate your help,
miloody
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinf
Hello! :-)
On Mon, Jun 15, 2009 at 5:08 PM,
wrote:
> Under Linux, I am not so sure. Anyway, libftdi and libusb both
> work under Linux, so there is no real need to use libftd2xx
> under Linux now that Nicolas says that there is no real performance
> gain to use libftd2xx under Linux.
Libftdi is
Tighten error handling on TAP enable/disable paths a bit:
- Don't enable/disable unless it's necessary. Those event
handlers could have nasty side effects...
- Don't *succeed* enables/disables if there was no code which
could have implemented that action. This prevents bugs like
wron
Fix a bug preventing ICEpick "enable that TAP" code from working:
the "runtest" command wrongly finished with a JTAG reset, discarding
the work the TAP enable handler just finished! Instead, JTAG should
stay in RUN/IDLE state.
---
src/jtag/tcl.c |2 +-
1 file changed, 1 insertion(+), 1 deleti
Extend the internal JTAG event handlers to cover enable/disable,
and use those events to make sure that targets get "examined" if
they were disabled when the scan chain was first set up:
- Remove "enum jtag_tap_event", merge with "enum jtag_event",
so C code can now listen for TAP enable/di
On Tuesday 16 June 2009, David Brownell wrote:
> Fix a bug preventing ICEpick "enable that TAP" code from working:
and FWIW, I've now seen ARM9 CPUs be properly enabled using
an ICEpick-C and set up so OpenOCD can talk to them.
Other than polishing off rough spots, I'll highlight two more
ta
At this time openocd is working quite well for me with 3 different jtag
adapters: rlink, jlink and olimex/ftdi. However, I have noticed a couple
of error recovery situations where it could get confusing for a user
(probably me). Possibly this has been discussed before but a quick look
at the ma
Hi,
I have just compiled OpenOCD and I had more problems then expected (more
then with the old version).
As my small contribution, I am making this summary so that it can
possibly be improuved.
svn version 2218, Ubuntu 8.04
1) When configure was checking for libftdxx, I had a bad time finding
w
On Jun 16, 2009, at 11:06 AM, Gene Smith wrote:
At this time openocd is working quite well for me with 3 different
jtag
adapters: rlink, jlink and olimex/ftdi. However, I have noticed a
couple
of error recovery situations where it could get confusing for a user
(probably me). Possibly this
Rick Altherr wrote:
>
> On Jun 16, 2009, at 11:06 AM, Gene Smith wrote:
>
>> At this time openocd is working quite well for me with 3 different jtag
>> adapters: rlink, jlink and olimex/ftdi. However, I have noticed a couple
>> of error recovery situations where it could get confusing for a user
Hello List,
I try to make a smoke test with the r2252.
But in case of my SAM7SE512 I got an error:
telnet:
> mww 0xf130 0x
mww write memory word [count]
Runtime error, file "command.c", line 469:
openocd:
Runtime error, file "command.c", line 469:
Runtime
Hi list,
This is minimal patch to support FA526 ARMv4 compatible core.
Since it is very similar to ARM920T I tried to reuse as much
code as possible.
CPU and board configs will follow soon.
BR,
Paulius Zaleckas
Index: src/target/fa526.c
=
On Tuesday 16 June 2009, Paulius Zaleckas wrote:
> This is minimal patch to support FA526 ARMv4 compatible core.
> Since it is very similar to ARM920T I tried to reuse as much
> code as possible.
>
> CPU and board configs will follow soon.
Also please update openocd.texi to list this (in alphabet
On Tue, 2009-06-16 at 23:16 +0200, Michael Fischer wrote:
> Hello List,
>
> I try to make a smoke test with the r2252.
> But in case of my SAM7SE512 I got an error:
>
> telnet:
> > mww 0xf130 0x
> mww write memory word [count]
> Runtime error, file "command.c",
Update the Beagle setup:
- OMAP3530 updates:
* split ICEpick TAP enable support to its own file, for
reuse and eventually for storing other utility code
like emulation reset
* clean up, including labeling the tap as for DAP not
for the Cortex-A8 and making endianness non
Let jtag_call_event_callbacks() behave when the callback removes itself.
Oddly, this crashed on x86_32 but not x86_64.
---
src/jtag/core.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Let jtag_call_event_callbacks() behave when the callback removes itself.
Oddly, this crashed on
DM6446 config updates:
- List two more TAPs, as disabled, mostly for doc purposes
- Included basic ICEpick support, still disabled by default
- Shorten line lengths
- Use $_TARGETNAME to configure the ETM and ETB
- This ARM core don't support endianness overriding
For now, boards that
Fix parsing bugs for "$target_name mww addr data [count]" ... it was
always requiring the count, instead of just defaulting it to one.
---
src/target/target.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Fix parsing bugs for "$target_name mww addr data [count]" ... it was
always r
Fix for a goofy "board" config ... reuse target/pxa270.cfg
instead of using a private copy.
---
tcl/board/crossbow_tech_imote2.cfg | 44 +++
1 file changed, 4 insertions(+), 40 deletions(-)
Fix for a goofy "board" config ... reuse target/pxa270.cfg
instead of usi
21 matches
Mail list logo
