On Tue, Nov 24, 2009 at 7:22 AM, Freddie Chopin wrote:
> Øyvind Harboe pisze:
>>
>> I can't seem to find the generic LPC config script work
>> that was done(but never committed).
>>
>> What was the story on why it wasn't committed yet?
>
> It's dead as IMHO it's impossible to make it generic, simp
On Tue, Nov 24, 2009 at 2:03 AM, Jerry Ling wrote:
> Many thanks for your improvement.
> This patch works very well.
Pushed.
Thanks for testing and providing a fix!
(Next time could you attach the patch as an email, I wasn't able to
read it in, but as it was only three lines so recreating it wa
Combined with Freddie's tips, you may be able to use some
of the OpenOCD GDB events...
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-deve
Øyvind Harboe pisze:
> I can't seem to find the generic LPC config script work
> that was done(but never committed).
>
> What was the story on why it wasn't committed yet?
It's dead as IMHO it's impossible to make it generic, simple and cover
all wicked types of use at the same time.
___
Thomas Kindler pisze:
> Hi!
>
> When single stepping on a STM32, I'm constantly caught in interrupt
> handler code. This makes debugging almost impossible for non-trivial
> programs with timer and other peripheral interrupts.
>
> I have seen that there's an "cortex_m3 maskisr on/off" command,
On Monday 23 November 2009, Thomas Kindler wrote:
> When single stepping on a STM32, I'm constantly caught in interrupt
> handler code. This makes debugging almost impossible for non-trivial
> programs with timer and other peripheral interrupts.
>
> I have seen that there's an "cortex_m3 maskis
On Monday 23 November 2009, David Brownell wrote:
> NOTE: this is partially broken, it seems to cause some
> other bug(s) to fire. Not sure what's up with that, yet.
The most blatant part of it is a bug in the resume() method, where
it misinterpreted an argument. Fixed by:
--- oocd.orig/src/ta
Actually, I ran into a possible other option:
git rebase -p master
which is supposed to preserve merges by not ignoring them. It seems to work
in the limited testing I've done. I'll wait for more commits on origin
before I confirm.
// Dean Glazeski
On Mon, Nov 23, 2009 at 6:24 PM, Zach Welch
Many thanks for your improvement.
This patch works very well.
BR,
--
Jerry
- Original Message -
From: "Øyvind Harboe"
To: "Jerry Ling"
Cc:
Sent: Monday, November 23, 2009 7:14 PM
Subject: Re: [Openocd-development] mips: remove dynamic arrays - reduces
stack usage
The patch didn't m
Looks great, but one minor comment below
On Tue, 2009-11-24 at 00:37 +0100, Andreas Fritiofson wrote:
> The previous implementation was unnecessarily complex. Get rid of the loops,
> let vsnprintf() tell us directly how much storage we need and allocate that. A
> second pass writes the actual
If you have a series (or tree) of branches, I wrote a small script to
rebase them automatically; however, it falls down when something fails,
in so far as you have to finish things manually (for now). Basically,
it does this process for N steps and for any number of branches in your
local web of c
Hi!
When single stepping on a STM32, I'm constantly caught in interrupt
handler code. This makes debugging almost impossible for non-trivial
programs with timer and other peripheral interrupts.
I have seen that there's an "cortex_m3 maskisr on/off" command, but it's
awkward to use from eclips
On Monday 23 November 2009, Øyvind Harboe wrote:
> Wow. :-)
I hope that's not all you'll have to say. ;)
Yeah, it just started growing... it's amazing how much custom
code can be needed when you bypass shared infrastructure.
I'm suspecting that one of the issues with that algorithm stuff
is br
The previous implementation was unnecessarily complex. Get rid of the loops,
let vsnprintf() tell us directly how much storage we need and allocate that. A
second pass writes the actual string. Also add a va_end() that was missing.
This should be much faster for large strings and less wasteful for
Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.
Update the user guide with information on where OpenOCD expects to find
configuration files and scripts. Also fixed some minor formatting issues.
Add entry to NEWS as well.
Signed
Wow. :-)
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-devel
On Mon, Nov 23, 2009 at 11:45 PM, Dean Glazeski wrote:
>> There's some documentation on minidrivers in openocd, but if
>> you are doing this for commercial reasons, then perhaps you would
>> like to contact Zylin to get a finished(or customizable by you/us)
>> solution? ;-)
>
> What about us poor
On Monday 23 November 2009, Liam Redmond (Rock Software) wrote:
> > Sadly, that also requires a lot of engineering expertise to write that
>
> Actually the hardware description is not as bad as you might first think, I
> have a prototype Xilinx CoolRunnerII CPLD hooked up to a Cypress high speed
This was private mechanism to snapshot registers before leaving
debug state, and then optionally display what changed. It was
coupled to the private register cache, which won't be sticking
around in that form for much longer. Remove (instead of teaching
it how to handle *all* the registers).
(Th
On Monday 23 November 2009, Dean Glazeski wrote:
> What about us poor graduate students who make less than unemployed people?
> I can't afford big name JTAG dongles! :) I would be very interested in
> trying to work on a project like this in the time I have available.
That's part of why I suggest
This finishes the basic switchover to the new register code,
for everything except the debug registers. (And maybe we
shouldn't have a cache for *those* which works this way...)
The context save/restore code now uses the new code, but
it's in a slightly different sequence. That should be fine
si
This is a very thin layer over some of the current ARM11
debug TAP utilities. The layer isn't yet hooked up.
---
src/target/arm11.h|4 ++
src/target/arm11_dbgtap.c | 73
src/target/arm11_dbgtap.h |3 +
3 files changed, 80 insertions(+
As with single stepping, the previous stuff was needed because
the ARM11 code wasn't using the standard ARM base type and
register access ... but now those mechanisms work, so we can
switch out that special-purpose glue, in favor of the more
thoroughly tested/capable "standard" code.
This should r
The previous stuff was needed because the ARM11 code wasn't using
the standard ARM base type and register access ... but now those
mechanisms work, so we can switch out that special-purpose glue.
This should resolve all the "FIXME -- handle Thumb single stepping"
comments too, and properly handle
This provides "standard" ARM register support -- with twenty or
more shadow registers on top of what this code now handles, but
properly associated with the various core modes -- parallel to
the current register code. That is, the current code is stilil
managing the "current" registers; the new co
First version of interface for sharing code between ARMv6 and ARMv7a
debug modules ... now the architecture includes debug support. (Not
the same as for the trimmed-down v7m or v6m though!) This is a first
version of an interface that will let the ARM11 and Cortex-A8 support
share code, features,
I'm posting this as an preview of some work that's not yet complete,
in case someone has insightful comments they want to share...
It's actually two things:
- ARM "Debug Programmer's Model" (DPM) for ARMv6/ARMv7 cores
(but not the M profiles, Cortex-M cores). Basically the
debug interf
>
> There's some documentation on minidrivers in openocd, but if
> you are doing this for commercial reasons, then perhaps you would
> like to contact Zylin to get a finished(or customizable by you/us)
> solution? ;-)
>
What about us poor graduate students who make less than unemployed people?
I c
I went ahead and moved everything over as a fork on my own. I'll leave the
other around until this stuff gets hammered out and I'll remove it at that
point. The new play area is http://repo.or.cz/w/openocd/dnglaze.git. I've
rebased everything to the new origin/master. Is there a good way to reb
> The FPGA isn't that difficult. I've created a similar setup using
> OpenOCD. The biggest problem I had was that OpenOCD is spending most of
> its time creating JTAG bit streams. Its not the bit-banging that takes
> most of the time! On a 333MHz platform it took about 15 minutes to
> program 180kB
On Mon, Nov 23, 2009 at 10:57 PM, Zach Welch wrote:
> On Mon, 2009-11-23 at 22:22 +0100, Andreas Fritiofson wrote:
>> On Sun, Nov 22, 2009 at 12:42 PM, Øyvind Harboe
>> wrote:
>> > On Sun, Nov 22, 2009 at 11:04 AM, Andreas Fritiofson
>> > wrote:
>> >> On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Har
On Mon, 2009-11-23 at 22:22 +0100, Andreas Fritiofson wrote:
> On Sun, Nov 22, 2009 at 12:42 PM, Øyvind Harboe
> wrote:
> > On Sun, Nov 22, 2009 at 11:04 AM, Andreas Fritiofson
> > wrote:
> >> On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe
> >> wrote:
> >>> Do not use variable length arrays. U
On Mon, 2009-11-23 at 13:04 -0600, Dean Glazeski wrote:
> Hi all,
>
> I've finished up the implementation and documentation for an AT91SAM9
> NAND driver for OpenOCD. In total there are about 34 patches that
> includes some refactor work for both the NAND controller layer and the
> ARM NAND I/O p
nand-refactor and armnandio can be applied in any order, but at91sam9-nand
must be after them I went ahead and fixed some of the tree problems that I
noticed with gitk to remove some redundant patches to make the dependencies
a bit clearer. I didn't mention this with the previous email, but I did
Thanks for following up on this. The style guide needs updating w.r.t.
embedded considerations(I was going to work on the style guide the
other day, but docs didn't build at the time and then I forgot about it...)
> However, alloc_vprintf() seems to have a rather cumbersome
> implementation. Is t
On Sun, Nov 22, 2009 at 12:42 PM, Øyvind Harboe wrote:
> On Sun, Nov 22, 2009 at 11:04 AM, Andreas Fritiofson
> wrote:
>> On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe
>> wrote:
>>> Do not use variable length arrays. Use malloc().
>>>
>>> If you use variable length arrays on the stack that mes
I took a super quick peek:
1. What's the order in which the branches should be applied?
2. The new .c file and modification of the Makefile.am belongs in the same
commit. Any reason why you split those into two commits?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale C
Hey,
Alright, I went through and reordered the patches and split a few of them
up. The result has been pushed to http://repo.or.cz/w/dnglaze.git. There
are now two additional branches:
master => synced manually with origin/master
armnandio => master + arm nand i/o patches
nand-refactor => maste
On Monday 23 November 2009, Dean Glazeski wrote:
> pieces. I have the branch posted at http://repo.or.cz/w/dnglaze.git under
> the at91sam9-nand head.
That's an intriguing and useful first: substantial patches
that could eventually be pulled from a "new" developers's
GIT branch! :)
That'll nee
On Monday 23 November 2009, Øyvind Harboe wrote:
> How's this?
Seems more plausible, and less certain to automagically
break working config scripts. :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/m
Wow. That's one big patch series. Great work! :-)
Did you run git rebase -i ? There seems to be some funny things going on
in that the at91sam9_nand.c is added in a *later* commit than the Makefile.am
is added.
This means that some of these commits won't compile...
If you haven't used git rebase
Hi all,
I've finished up the implementation and documentation for an AT91SAM9 NAND
driver for OpenOCD. In total there are about 34 patches that includes some
refactor work for both the NAND controller layer and the ARM NAND I/O
pieces. I have the branch posted at http://repo.or.cz/w/dnglaze.git
How's this?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From 828d006a9d05b24b6dcdf1c552912e04586d6f7d Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?=
Date: Mon, 23 Nov 2009 18:23:10 +0100
Subject: [PATCH] ar
On Mon, Nov 23, 2009 at 6:10 PM, David Brownell wrote:
> On Monday 23 November 2009, Ųyvind Harboe wrote:
>> The only user of arm920t in the tcl directory is csb337.cfg.
>
> I can change that, assuming the replacement code actually works,
> but I want to finish the arm11 register rework first ...
On Monday 23 November 2009, Nico Coesel wrote:
> The biggest problem I had was that OpenOCD is spending most of
> its time creating JTAG bit streams. Its not the bit-banging that takes
> most of the time! On a 333MHz platform it took about 15 minutes to
> program 180kB into flash (with an FPGA for
On Monday 23 November 2009, Øyvind Harboe wrote:
> The only user of arm920t in the tcl directory is csb337.cfg.
I can change that, assuming the replacement code actually works,
but I want to finish the arm11 register rework first ... first
patches on that will come later today, I hope.
BTW I thnk
On Mon, Nov 23, 2009 at 2:55 PM, Zach Welch wrote:
> On Mon, 2009-11-23 at 14:19 +0100, Øyvind Harboe wrote:
>> Would anyone mind if the arm920t and arm720t cp15 commands
>> were retired?
>>
>> The only user of arm920t in the tcl directory is csb337.cfg.
>>
>> If someone could offer a translation
On Mon, 2009-11-23 at 14:19 +0100, Øyvind Harboe wrote:
> Would anyone mind if the arm920t and arm720t cp15 commands
> were retired?
>
> The only user of arm920t in the tcl directory is csb337.cfg.
>
> If someone could offer a translation of the "arm920t cp15 2 0xc0001078"
> command to "mcr" synt
Would anyone mind if the arm920t and arm720t cp15 commands
were retired?
The only user of arm920t in the tcl directory is csb337.cfg.
If someone could offer a translation of the "arm920t cp15 2 0xc0001078"
command to "mcr" syntax + test it. We'd be ready to retire
the arm920t/arm720t commands in
These are now handled by the generic mrc/mcr commands.
Testing much appreciated!
arm720t, arm920t has cp15 specific commands that I believe
can be replaced by the generic mrc/mcr syntax, but I haven't
deciphered the syntax of those cp15 commands.
--
Øyvind Harboe
http://www.zylin.com/zy1000
The patch didn't make it through.
Please check this patch and I'll commit it.
Sorry about breaking the mips stuff & thanks for spotting it!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From 308f6494e8c1281f4f17e821911043267e
Hi Oyvind,
Please see the patch below.
Please update the parameter num_param_in of mips32_pracc_exec while removing
dynamic arrays.
Thanks.
- Jerry
--- a/src/target/mips32_pracc.c
+++ b/src/target/mips32_pracc.c
@@ -618,11 +618,11 @@ int mips32_pracc_write_mem32(struct mips_ejtag
*ejtag_info,
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Duane Ellis
> Sent: zaterdag 21 november 2009 16:42
> To: Openocd-Dev
> Subject: [Openocd-development] Openocd vrs Commercial jtag dongles
>
> Rec
> Sadly, that also requires a lot of engineering expertise to write that
Actually the hardware description is not as bad as you might first think, I
have a prototype Xilinx CoolRunnerII CPLD hooked up to a Cypress high speed
FX2, this effectively gives a direct pipe from the OpenOCD USB calls to
54 matches
Mail list logo
