On Sat, 2009-12-05 at 08:35 +0100, Øyvind Harboe wrote:
> The approach seems to work fine, but requires that some other
> issues are sorted out first with include dirs.
>
> >From error message above, there are two "strange" -I additions:
>
> NB! build != src dir
>
> -I. => current build directory
On Fri, 2009-12-04 at 23:31 -0800, David Brownell wrote:
> On Tuesday 01 December 2009, Zach Welch wrote:
> > We should approach this problem as though we intend to eventually
> > decouple Jim from the core functionality and switch to a different
> > front-end language.
>
> That's a useful stateme
How about shooting for a release candidate in beginning of
january?
There are some general "factory shutdowns" coming up, were
we couldn't really expect any serious testing; a good time
to stabilize the code and not to commit anything
drastic.
--
Øyvind Harboe
US toll free 1-866-980-3434 / Inte
The approach seems to work fine, but requires that some other
issues are sorted out first with include dirs.
From error message above, there are two "strange" -I additions:
NB! build != src dir
-I. => current build directory
-I../.. => this is the root build dir, so I would have to include
inclu
On Fri, 2009-12-04 at 23:03 -0800, David Brownell wrote:
> Just a heads-up/ping ... the original notion of the 0.4.0 schedule
> has RC1 in a couple weeks, and I think we should still plan on that.
>
> Is any ongoing major work not likely to finish by then?
Yes, but that doesn't mean it can't be p
On Tuesday 01 December 2009, Zach Welch wrote:
> We should approach this problem as though we intend to eventually
> decouple Jim from the core functionality and switch to a different
> front-end language.
That's a useful statement of the extreme, but note that it's in
two parts: decouple ... and
This worked pretty well, but there are lots of (to me) inexplicable
-I's on the command line still and none of them point to the right
place in the build tree. I'm testing minidummy build != src dir.
oharboe/fixminidriver2
../openocd/configure --enable-minidriver-dummy --enable-maintainer-mode
m
Committed both patches; thanks!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Just a heads-up/ping ... the original notion of the 0.4.0 schedule
has RC1 in a couple weeks, and I think we should still plan on that.
Is any ongoing major work not likely to finish by then?
Are there patches that seem to have been forgotten, which should
not have been? If so, please repost aga
On Fri, 2009-12-04 at 20:54 -0800, David Brownell wrote:
> On Friday 04 December 2009, Zach Welch wrote:
> > Sounds good to me. I have given the target directory a wide berth since
> > you have been working on it. ;)
>
> Glad to hear it. :)
>
> I pushed; N == 10.
>
> This should be the bulk of
Fall back to software breakpoint when vector catch isn't available.
Possible enhancements:
- add extra optional command parameter to select high vectors
- add extra optional command parameter to select hardware breakpoint
Signed-off-by: Nicolas Pitre
---
src/target/arm7_9_common.c | 16 +++
Signed-off-by: Nicolas Pitre
---
src/target/arm_semihosting.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/target/arm_semihosting.c b/src/target/arm_semihosting.c
index 39625f6..d448d54 100644
--- a/src/target/arm_semihosting.c
+++ b/src/target/arm_semihos
On Friday 04 December 2009, Zach Welch wrote:
> Sounds good to me. I have given the target directory a wide berth since
> you have been working on it. ;)
Glad to hear it. :)
I pushed; N == 10.
This should be the bulk of the renames ... the other "have ARM be
more generic" stuff will be less in
Sounds good to me. I have given the target directory a wide berth since
you have been working on it. ;)
On Fri, 2009-12-04 at 19:29 -0800, David Brownell wrote:
> I'm committing some renaming patches, which help move the
> stuff in "armv4_5.h" more towards being generic ARM stuff.
>
> Sample pat
I'm committing some renaming patches, which help move the
stuff in "armv4_5.h" more towards being generic ARM stuff.
Sample patch appended ... they're all equally boring, so
I won't be posting every one of them. They're done by
more or less
for F in $(grep -rl OLD src)
do
As with Cortex-A8, the WFAR register holds useful information
that should be recorded and, where relevant, displayed.
---
src/target/arm11.c | 18 ++
1 file changed, 18 insertions(+)
--- a/src/target/arm11.c
+++ b/src/target/arm11.c
@@ -217,6 +217,19 @@ static int arm11_debug_en
Tweak scanchain 7 debug messaging:
- show register addresses in decimal, matching ARM docs;
- remove some pointless noise
Avoid some needless roundtrips:
- skip SCAN_N when SCREG already holds that number (speeds up
polling and other common operations)
- avoid zeroing vcr twice on resume
Use the DPM watchpoint support; remove old incomplete stubs.
---
So at this point, add watchpoint support to the DPM framework
and several hundred lines can vanish from ARM11 and Cortex-A8...
NEWS |2
src/target/arm11.c|3 -
src/target/arm11.h|3 -
On Fri, 2009-12-04 at 19:45 -0600, Dean Glazeski wrote:
> Don't mind me when it comes to the NAND. I won't be active probably
> until Christmas break when I no longer have persistent projects :).
> At that time I welcome the challenge of forcing my stuff into the
> proper mold. I'll have to make
Don't mind me when it comes to the NAND. I won't be active probably until
Christmas break when I no longer have persistent projects :). At that time
I welcome the challenge of forcing my stuff into the proper mold. I'll have
to make a list. Have fun!
// Dean Glazeski
On Fri, Dec 4, 2009 at
On Fri, 2009-12-04 at 03:43 -0800, Zach Welch wrote:
[snip]
> > The last two patches begin to split the NOR flash layer into
> > public and private APIS (, respectively)
> > and into core and TCL modules (flash/nor/{core,tcl}.c, likewise).
> >
> > More patches will be required to finish this job,
On Fri, 2009-12-04 at 21:46 -0300, Esteban Lucchesi wrote:
> Hi all,
> I'm new to the list. I've read it often these last days because I
> bought a Hitex LPC-Stick for the LPC2468 and I wanted to make it work
> with Eclipse+Yagarto+OpenOCD.
> I added the layout "lpcstick" to ft2232.c and the corres
Hi all,
I'm new to the list. I've read it often these last days because I bought a
Hitex LPC-Stick for the LPC2468 and I wanted to make it work with
Eclipse+Yagarto+OpenOCD.
I added the layout "lpcstick" to ft2232.c and the corresponding functions
lpcstick_init() and lpcstick_reset().
Although I st
On Friday 04 December 2009, Nicolas Pitre wrote:
> On Fri, 4 Dec 2009, David Brownell wrote:
>
> > Clean up arm_semihosting() entry a bit, comment some issues and just
> > which SVC opcodes are getting intercepted. Microcontroller profile
> > cores will need a new entry, since they don't use SVC
On Fri, 2009-12-04 at 22:51 +0100, Øyvind Harboe wrote:
> On Fri, Dec 4, 2009 at 10:36 PM, Zach Welch wrote:
> > On Fri, 2009-12-04 at 16:03 +0100, Øyvind Harboe wrote:
> >> It's getting there, see oharboe/fixminidriver.
> >>
> >> I had to mess with lots of Makefile.am to pollute the include path.
On Fri, Dec 4, 2009 at 10:36 PM, Zach Welch wrote:
> On Fri, 2009-12-04 at 16:03 +0100, Øyvind Harboe wrote:
>> It's getting there, see oharboe/fixminidriver.
>>
>> I had to mess with lots of Makefile.am to pollute the include path. If I
>> can get that out of the way, then I should be able to cle
On Fri, 2009-12-04 at 16:03 +0100, Øyvind Harboe wrote:
> It's getting there, see oharboe/fixminidriver.
>
> I had to mess with lots of Makefile.am to pollute the include path. If I
> can get that out of the way, then I should be able to clean up the
> rest too
Yeah, those changes should not go i
On Fri, 4 Dec 2009, David Brownell wrote:
> Clean up arm_semihosting() entry a bit, comment some issues and just
> which SVC opcodes are getting intercepted. Microcontroller profile
> cores will need a new entry, since they don't use SVC there (or even
> have an SVC mode).
In that case they use
Clean up arm_semihosting() entry a bit, comment some issues and just
which SVC opcodes are getting intercepted. Microcontroller profile
cores will need a new entry, since they don't use SVC there (or even
have an SVC mode).
---
Compile tested.
src/target/arm_semihosting.c | 44
Store a flag and errno in in "struct arm".
Have "poll" output report when semihosting is active.
Shrink some of the affected lines.
---
Compile-tested only.
src/target/arm7_9_common.c | 22 --
src/target/arm_semihosting.c | 39 ++-
src
List it in the concept index, in the section about target software
changes a project might want to consider, and in the section about
debug messaging.
---
doc/openocd.texi | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.tex
On Thursday 03 December 2009, Nicolas Pitre wrote:
> Interest is pretty evident when you want to display debugging
> information from code running on a target without a serial port for
> example, or during early board bringup when there is simply no code yet
> to drive the serial port. This is
It's getting there, see oharboe/fixminidriver.
I had to mess with lots of Makefile.am to pollute the include path. If I
can get that out of the way, then I should be able to clean up the
rest too.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.co
Zach Welch a écrit :
> Is it just me, or is there a missing ' ' in your indentation?
> Things don't appear to line up right in the patch for me...
Not too sure where you see the space missing. Can you be more precise?
> Otherwise, it looks good! Minor nits below.
>> + if test "$FTDILIBS" = ""
On Thu, 2009-12-03 at 18:04 -0800, Zachary T Welch wrote:
> Hi all,
>
> The first two patches work to eliminate some Jim handling in the
> helper and JTAG modules, with the later being nearly purged.
> If the command layer provides some wrappers for Jim's return
> handling mechanisms, then all han
On Fri, Dec 4, 2009 at 12:32 PM, Zach Welch wrote:
> On Fri, 2009-12-04 at 02:31 -0800, David Brownell wrote:
>> On Friday 04 December 2009, Øyvind Harboe wrote:
>> > That's better.
>>
>> It's an ugly hack that's papering over some real bug.
>>
>> Why was the JTAG initialization bypassed? The stu
On Fri, 2009-12-04 at 02:31 -0800, David Brownell wrote:
> On Friday 04 December 2009, Øyvind Harboe wrote:
> > That's better.
>
> It's an ugly hack that's papering over some real bug.
>
> Why was the JTAG initialization bypassed? The stuff
> that forces the equivalent of "jtag_reset 0 0" ?
I j
Is it just me, or is there a missing ' ' in your indentation?
Things don't appear to line up right in the patch for me...
Otherwise, it looks good! Minor nits below.
On Fri, 2009-12-04 at 12:05 +0100, Albert ARIBAUD wrote:
> (apologies, David, for the private-only mail)
>
> David Brownell a écri
I think this work will ultimately benefit the design and
quality of code in OpenOCD.
If someone wants to use a different language than
Tcl, then I certainly don't want to take that away from
them.
I'm also confident that you see the advantages of choosing
a single language in which to ship target
(apologies, David, for the private-only mail)
David Brownell a écrit :
> On Friday 04 December 2009, Albert ARIBAUD wrote:
>> While at it, the OpenOCD configure.in should use pgk-config or
>> libftdi-config to find out the current LIBFTDI libs and CFLAGS,
>> especially the include path.
>
>
>
On Fri, 2009-12-04 at 11:38 +0100, Øyvind Harboe wrote:
> >> There would have to be some huge advantage or some
> >> robust way of getting retesting done.
> >
> > Actually... there's a very simple idea: heterogeneous language support.
>
> To me that sounds like a disadvantage. I like the simplicit
>> There would have to be some huge advantage or some
>> robust way of getting retesting done.
>
> Actually... there's a very simple idea: heterogeneous language support.
To me that sounds like a disadvantage. I like the simplicity and confines
of jim tcl.
>> Your improved design can facilitate s
On Friday 04 December 2009, Øyvind Harboe wrote:
> That's better.
It's an ugly hack that's papering over some real bug.
Why was the JTAG initialization bypassed? The stuff
that forces the equivalent of "jtag_reset 0 0" ?
> I still get error messages on startup(it should have
> examined the JTA
On Friday 04 December 2009, Albert ARIBAUD wrote:
> While at it, the OpenOCD configure.in should use pgk-config or
> libftdi-config to find out the current LIBFTDI libs and CFLAGS,
> especially the include path.
Feel free to craft that patch. :)
___
On Fri, 2009-12-04 at 10:39 +0100, Øyvind Harboe wrote:
> On Fri, Dec 4, 2009 at 10:31 AM, Zach Welch wrote:
> > On Fri, 2009-12-04 at 07:48 +0100, Øyvind Harboe wrote:
> >> On Fri, Dec 4, 2009 at 3:04 AM, Zachary T Welch
> >> wrote:
> >> > Commands that do not need to use Jim should be register
That's better.
I still get error messages on startup(it should have
examined the JTAG chain), but it works.
Info : clock speed 16000 kHz
Error: The 'init' command must be used before 'init'.
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.
Init complete,
Hi,
While at it, the OpenOCD configure.in should use pgk-config or
libftdi-config to find out the current LIBFTDI libs and CFLAGS,
especially the include path.
Regards,
Albert.
David Brownell a écrit :
> Reason for OpenOCD folk to care is that "previously failed..."
> below.
>
> Y'all are enc
Reason for OpenOCD folk to care is that "previously failed..."
below.
Y'all are encouraged to test...
-- Forwarded Message --
Subject: Re: Patches applied
Date: Friday 04 December 2009
From: Thomas Jarosch
To: libf...@developer.intra2net.com
Hello Jim,
On Thursday, 3. Decemb
On Thursday 03 December 2009, Øyvind Harboe wrote:
> Error: The 'init' command must be used before 'init'.
> Command handler execution failed
> Warn : jtag initialization failed; try 'jtag init' again.
Yeah, everything seems to cause JTAG init to fail lately.
One issue seems to be:
=
On Fri, Dec 4, 2009 at 10:36 AM, Zach Welch wrote:
> This is actually expected; there was no warning previously, and the
> dummy driver always fails because it returns garbage.
The error message is nonsensical and offers no clues as to what
is wrong, or what needs to be fixed.
The error message
On Fri, Dec 4, 2009 at 10:31 AM, Zach Welch wrote:
> On Fri, 2009-12-04 at 07:48 +0100, Øyvind Harboe wrote:
>> On Fri, Dec 4, 2009 at 3:04 AM, Zachary T Welch
>> wrote:
>> > Commands that do not need to use Jim should be registered as
>> > high-level command handlers.
>>
>> Why is that?
>>
>> N
This is actually expected; there was no warning previously, and the
dummy driver always fails because it returns garbage.
It still starts up, right? The fact that it is telling you where
something failed is a good thing, if were talking about real hardware...
right?
--Z
On Fri, 2009-12-04 at 08
On Fri, 2009-12-04 at 07:48 +0100, Øyvind Harboe wrote:
> On Fri, Dec 4, 2009 at 3:04 AM, Zachary T Welch
> wrote:
> > Commands that do not need to use Jim should be registered as
> > high-level command handlers.
>
> Why is that?
>
> Nb! "ls" *does* need to use jim to return a list of directory
When tools are not installed, exit immediately. This makes
the error messages clearer.
Signed-off-by: Øyvind Harboe
---
bootstrap |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/bootstrap b/bootstrap
index 7684dc4..268d07c 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1,6
54 matches
Mail list logo
