> Which means the bug is between 788 - 729...
>
> If you give me the precise test procedure you use, I've got
> two arm926ejs targets I can test on here.
>
> --
> Øyvind Harboe
> Embedded software and hardware consulting services
> http://www.zylin.com
--
--
Dominic Rath
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
--
--
Dominic Rath
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
gt; --
> Øyvind Harboe
> http://www.zylin.com/zy1000.html
> ARM7 ARM9 XScale Cortex
> JTAG debugger and flash programmer
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailma
Hi,
the OpenOCD contains support for some controllers with NAND interfaces, but
the AT91SAM9260 isn't currently supported. I looked into this once, but
SAM-BA is so easy to use, I didn't bother working on OpenOCD support for the
SAM9s.
There's a Linux version of SAM-BA (I never used the Window
Is there any other ARM SAM9 compatible programmer that works under linux
> ?
>
> * What are your suggestions with the at91sam9 controllers ?
>
>
> I would really appreciate any help that brings me forward.
>
> sincerly,
> stefan
Regards,
Dominic
--
--
Dominic Rath <[EMAIL PROTECTED]>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
ces, all of which would need a WIN+FTD2XX and a *NIX+libftdi (I've got to
think a bit more if there are differences between *nix+libftdi and *nix+FTD2XX
- in that case we'd have a third alternative...).
Any way - I'm fine with eith
Hello Christian,
On Thursday 07 August 2008 04:06:53 Christian Jaeger wrote:
> I had been using (amongst a few other settings) this config at first:
>
> interface ft2232
> ft2232_device_desc "Olimex OpenOCD JTAG TINY"
> ft2232_layout olimex-jtag
>
> where the desc was taken from /sys/bus/usb/de
communication in general.
>
> I guess I want(like gdb?) to add all breakpoints on resume and remove them
> upon detected halt.
>
> Configuration of breakpoints should not touch the hardware.
That would slow down single-step or halt/resume operation.
--
--
Dominic Rath <[EMAIL PROTECTED]>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
th 6 bytes of minimum
payload...
I honstely doubt RLE has any negative effect because of packet lengths...
Regards,
Dominic
--
--
Dominic Rath <[EMAIL PROTECTED]>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https
On Sunday 27 July 2008 11:18:30 you wrote:
> On Sun, Jul 27, 2008 at 11:09 AM, Dominic Rath <[EMAIL PROTECTED]> wrote:
> > On Saturday 26 July 2008 10:55:43 Øyvind Harboe wrote:
> >> I'd like to retire reset "run_and_halt" and "run_and_init",
&
On Saturday 26 July 2008 10:55:43 Øyvind Harboe wrote:
> I'd like to retire reset "run_and_halt" and "run_and_init",
> they are completely redundant.
>
> This simplifies the target_process_reset code and also makes
> the documentation of reset less noisy.
>
>
> This would leave us with three atomic
On Friday 25 July 2008 20:21:02 Kishore wrote:
> On Friday 25 Jul 2008 11:16:57 pm Dominic Rath wrote:
> > You'll probably have to look for another platform then. PowerPCs come
> > with a debug interface, but there's little or no documentation to get
> > hold off. MI
On Friday 25 July 2008 19:20:08 you wrote:
> I've used commercial debuggers that use the 4 JTAG signals in order to
> establish a debugging session
Have you debugged x86 targets that way? Is is possible for e.g. ARM (though
without reset signals you're rather limited).
> and I know the ARM guys
On Thursday 24 July 2008 21:37:41 Brian Hutchinson wrote:
> Hi,
>
> Could someone point me in the right direction so I don't go in the weeds
> too far?
>
> I know this is mostly for ARM but I would really like to take a interface
> line the Amontec JAGKey Tiny and make an adaptor to match the pinou
On Wednesday 23 July 2008 21:19:50 you wrote:
> I've committed the fix for " is missing" problem.
Thanks.
> > * Also, since the halt() is asynchronous target connect will be
> > * instantaneous and thus avoiding annoying timeout problems during
> > * connect.
> > */
> >
> > The a
On Tuesday 22 July 2008 23:17:40 you wrote:
> Take #2
>
> Perhaps poll() has not been invoked?
That didn't fix it either. The situation is actually worse than just a bogus
0x0 which can be easily identified.
[EMAIL PROTECTED]:~/arm$
ntoarm-gdb
/home/vmaster/arm/qnx/workspace/sam9_l9260/Images/
On Tuesday 22 July 2008 22:15:08 you wrote:
> > -gdb-gdb-gdb-gdb-
> >--- [EMAIL PROTECTED]:~/arm$
> > ntoarm-gdb
> > /home/vmaster/arm/qnx/workspace/sam9_l9260/Images/startup-at91sam9263ek.s
> >ym GNU gdb 6.7
> > Copyright (C) 2007 Free So
Hi list,
is it possible that GDB support in OpenOCD is currently at least partially
broken? Are there known bugs that came with TCL, is this something unrelated,
but known, or is this something new?
I let the OpenOCD attach to a running target (AT91SAM9260, currently executing
u-boot), poll th
On Sunday 20 July 2008 20:15:38 you wrote:
> On Sun, Jul 20, 2008 at 7:51 PM, Dominic Rath <[EMAIL PROTECTED]> wrote:
> > Hi list,
> >
> > while working with the OpenOCD's telnet interface for a bit I got several
> > of these messages:
> >
> > ke
Hi list,
while working with the OpenOCD's telnet interface for a bit I got several of
these messages:
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not
sent! (1258)
I had the jtag_speed set to a very high value (1400), because the target is an
ARM926EJ-S core running
Hi list, and especially the TCL gurus,
I just tried the current SVN head a bit, and quickly realized that incomplete
commands didn't work anymore.
I remember reading something about this in one of the recent mails, but can't
find it right now. Is that functionality only temporarily gone, or is
On Sunday 20 July 2008 19:25:07 Øyvind Harboe wrote:
> I've got some thoughts on defining a crisper interface between the
> target_process_reset() and the target.
>
> - the idea is to let the target be ignorant of reset modes. Reset
> modesrun, init,
> halt, run_and_init, etc. is something that is
is to keep the end users life tcl free.
> >
> > I suppose your end user is someone who doesn't write config scripts,
> > but merely uses your target library, right?
>
> I want to keep tcl out of the face of end users who writes c
d user is someone who doesn't write config scripts, but merely
uses your target library, right?
--
--
Dominic Rath <[EMAIL PROTECTED]>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
t things, so maybe we
should drop it?
One comment regarding the use of TCL in this discussion: I completely dislike
the idea of having to write TCL code to be able to conserve functionality that
used to work before. Scripting isn't everyone'
On Monday 14 July 2008 19:34:06 you wrote:
> This is work in progress. Development happens on trunk and we'll
> have to cut stable branches if need be.
>
> There is a great need to synchronize work because many people are
> involved. Both "scripting" people and C people.
>
> Once the dust settles(g
Hi List,
unfortunately I don't have nearly enough time to follow all the changes going
on in the OpenOCD SVN repository, but I'd like to make some comments here:
- Some people have raised concerns about the direction of OpenOCD development.
The use of TCL for integral parts of the OpenOCD seems
27 matches
Mail list logo
