> -Oorspronkelijk bericht-
> Van: Zach Welch [mailto:z...@superlucidity.net]
> Verzonden: woensdag 13 mei 2009 13:17
> Aan: Nico Coesel
> CC: openocd-development
> Onderwerp: jtag driver tutorial (was RE:
> [Openocd-development] doxygen update)
>
> On Tue, 2009-05-12 at 00:19 +0200, Ni
Could this be an intermittant problem?
I was able to reproduce this problem *once* using 1770 and
the script below on a parport interface with an LPC2148 target
and the command below:
reset init
for {set i 0} {$i < 100} {set i [expr $i+1]} {puts $i ; dump_image
c:\\temp\\test.bin 0x4000 0x80
I've worked a bit more on testing lpc2148 and except for that *one*
time I haven't seen the error you saw.
Perhaps this is easier to reproduce on an ft2232 adapter?
Below are some commands I used to run a 1000 iterations of this test...
# tried messing about with options...
arm7_9 fast_memory_ac
I've been thinking a bit about a selftest script:
- write a script that can run basic tests on all targets
- this script will need some parameters: working memory,
where to store temporary files, etc.
- each target will have permutations that need testing. E.g.
arm7/9 it makes sens to test with an
the -endstate ir/drscan option is broken.
It would set endstate for the *next* JTAG operation
rather than the current ir/drscan...
Comments?
Can someone test this before I commit it?
irscan omap3.jrc 7 -endstate IRPAUSE
drscan omap3.jrc 8 0x89 -endstate DRPAUSE
irscan o
Hi
I believe I have found a bug resulting in OpenOCD unable to program an 8-bit
CFI flash which does not support buffered writes.
The device in question in a Spansion S29AL032D.
The device reports cfi_info->max_buf_write_size == 0 indicating that it does
not support buffered writes, but they are
No attachment.
On May 14, 2009, at 8:47 AM, Gareth McMullin wrote:
Hi
I believe I have found a bug resulting in OpenOCD unable to program
an 8-bit CFI flash which does not support buffered writes.
The device in question in a Spansion S29AL032D.
The device reports cfi_info->max_buf_write_s
Hello all:
I have noticed some issues on CFI flash driver related to chip and bus width
affecting read and writes.
The system I'm dealing with is based on a Vitesse switch chip which embeds
an ARM926ejs processor. It additionally provides RAM and flash controller. In
this case we are us
On Thu, 2009-05-14 at 12:36 +0200, Øyvind Harboe wrote:
> I've been thinking a bit about a selftest script:
>
> - write a script that can run basic tests on all targets
> - this script will need some parameters: working memory,
> where to store temporary files, etc.
> - each target will have permu
On Thu, May 14, 2009 at 7:45 PM, Zach Welch wrote:
> On Thu, 2009-05-14 at 12:36 +0200, Øyvind Harboe wrote:
>> I've been thinking a bit about a selftest script:
>>
>> - write a script that can run basic tests on all targets
>> - this script will need some parameters: working memory,
>> where to s
Committed.
Any testing feedback here is appreciated.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mail
Committed.
dump_image was broken for 32 bit aligned addresses.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/target.c
===
--- src/target/target.c (revision 1782)
+++ src/target/target.c (working copy)
@@ -2133,7 +2133
On Wed, 2009-05-13 at 23:55 +0200, Magnus Lundin wrote:
> Zach Welch wrote:
> > Magnus, (resent w/ Reply-All... oops)
> >
> > Please let me know if there is anything that I can do to help this
> > situation. I am sorry that you are so frustrated right now, and I wish
> > there was something that
On Thu, 2009-05-14 at 09:17 +0200, Nico Coesel wrote:
>
> > -Oorspronkelijk bericht-
> > Van: Zach Welch [mailto:z...@superlucidity.net]
> > Verzonden: woensdag 13 mei 2009 13:17
> > Aan: Nico Coesel
> > CC: openocd-development
> > Onderwerp: jtag driver tutorial (was RE:
> > [Openocd-d
Hi all,
The OpenOCD community has recently experienced a series of unpleasant
situations that have negatively affected the project's cohesiveness.
>From my perspective, the lack of clear and consistent policies and
behaviors on the part of the project maintainers have been to blame for
these si
No known regressions in performance or functionality as
of writing in 1786 vs. 1606(before JTAG API rewrite).
If you have a problem with svn head that does not exist in 1606
I would very much like to hear from you on the list.
Michael Fischer found an intermittent problem with dump_image on
lpc22
Raúl Sánchez Siles wrote:
> Hello all:
>
> I have noticed some issues on CFI flash driver related to chip and bus
> width
> affecting read and writes.
>
> The system I'm dealing with is based on a Vitesse switch chip which embeds
> an ARM926ejs processor. It additionally provides RAM and
Rick,
Following on my post about maintainer roles, I wanted to see if I could
talk you into seizing the responsibilities and authority for the release
process, with the particular mindset of getting us rolling toward 0.2.0.
I am willing to support you in whatever way possible to make it happen.
I
Raúl,
I posted a patch that does take the bus and chip width into account a short
while ago. Anyway, if your flash is 8 bit, then your bus must be 8 bits wide.
It is not clear whether you have two 8 bit flashes in parallel to form a 16 bit
flash.
Nico
Hello all:
I have noticed some issu
Hello,
I'm new to openocd, and I just joined the mailing list today. I've tried
openocd a couple of times in the past I have to say I'm much more impressed
with the state of things now than I was a year ago. I'm working on an
open-source imx27 board. I just read Zach's message on maintainer roles
On Thursday 14 May 2009, Nico Coesel wrote:
> Anyway, if your flash is 8 bit, then your bus must be
> 8 bits wide.
Not true; there *is* support, e.g. in Linux, for hooking
up two 8-bit NOR chips in parallel. I think one of the
ideas is to improve the read/write bandwidth.
> It is not clear w
On Thu, 2009-05-14 at 13:27 -0700, Paul Thomas wrote:
> Hello,
>
> I'm new to openocd, and I just joined the mailing list today. I've
> tried openocd a couple of times in the past I have to say I'm much
> more impressed with the state of things now than I was a year ago.
> I'm working on an open-s
Hi all,
I spent a few hours** playing with Perl and followed through with a
couple of ideas that had floated through the list in the past. The
results of that work are attached. Share and enjoy.
The first file, JTAG.pm, is a Perl module that defines the TAP state
machine and provides routines f
On Thu, May 14, 2009 at 2:35 PM, Zach Welch wrote:
> On Thu, 2009-05-14 at 13:27 -0700, Paul Thomas wrote:
> > Hello,
> >
> > I'm new to openocd, and I just joined the mailing list today. I've
> > tried openocd a couple of times in the past I have to say I'm much
> > more impressed with the state
Hello,
I'm trying to use the load_image command, and it keeps giving me an error. I
know the command syntax is correct because this works on a different imx27
board. I would think it's just my SDRAM initilization except that I can
read/write to the memory with mww and mdw. You can see the full out
On Thu, 2009-05-14 at 14:46 -0700, Paul Thomas wrote:
[snip]
> Thanks Zach, here's the cfg file.
In the future, even new files should be submitted as a patch, as I was
not immediately _certain_ where you wanted me to put this. A patch made
from the root of the tree would eliminate all doubt. Nev
On Thu, May 14, 2009 at 11:56 PM, Paul Thomas wrote:
> Hello,
>
> I'm trying to use the load_image command, and it keeps giving me an error. I
> know the command syntax is correct because this works on a different imx27
> board. I would think it's just my SDRAM initilization except that I can
> re
On Thu, May 14, 2009 at 4:29 PM, Øyvind Harboe wrote:
> On Thu, May 14, 2009 at 11:56 PM, Paul Thomas
> wrote:
> > Hello,
> >
> > I'm trying to use the load_image command, and it keeps giving me an
> error. I
> > know the command syntax is correct because this works on a different
> imx27
> > boa
On Thu, May 14, 2009 at 4:34 PM, Paul Thomas wrote:
> On Thu, May 14, 2009 at 4:29 PM, Øyvind Harboe wrote:
>
>> On Thu, May 14, 2009 at 11:56 PM, Paul Thomas
>> wrote:
>> > Hello,
>> >
>> > I'm trying to use the load_image command, and it keeps giving me an
>> error. I
>> > know the command syn
On Thursday 14 May 2009, Paul Thomas wrote:
> mww and mdw only work to for the first 32k
But I used them just today to reference an address
up around 0x01c40800, which is much higher than that.
So that can't be the issue...
I do see that "BUG: unknown debug reason:" a lot
(almost always with 0x
On Thu, May 14, 2009 at 5:00 PM, David Brownell wrote:
> On Thursday 14 May 2009, Paul Thomas wrote:
> > mww and mdw only work to for the first 32k
>
> But I used them just today to reference an address
> up around 0x01c40800, which is much higher than that.
>
> So that can't be the issue...
>
>
Alternatively, maybe the folk who now have responsibilities
http://developer.berlios.de/project/memberlist.php?group_id=4148
could start by saying how they see their roles, and what they
see the process as being ... and what it *should* be, vs where
it's now broken. (The "skills" pages are uni
Hi all,
I want everyone to know The List has hit the repository in r1791.
It has evolved beyond my ability to manage it without some help.
There has been so much activity lately that I know some things may have
slipped through the cracks. At this point, the amount of time it will
take me to find
On Thursday 14 May 2009, Zach Welch wrote:
> If you are still willing continue in this role, I would like to see you
> document the release processes (perhaps in doc/manual/releases.txt?) and
> inform the rest of us what we need to do to make 0.2.0 a reality.
Heck ... even if you're not willing, I
On Thursday 14 May 2009, Paul Thomas wrote:
> Your a busy guy David. Last we spoke you figured out the missing bit to make
> some of v4l stuff work with arm.
Nah, that was just remembering old USB discussions that
seem to have gotten dropped by V4L people. You were the
guy who finally closed that
On Thursday 14 May 2009, Zach Welch wrote:
> I think that these links catapult The List
> beyond a mere TODO or task list. It has started to provide references
> to explain how the items got there in the first place, and I would like
> to see it grow further into a means of outlining the progress
On Thu, 2009-05-14 at 17:52 -0700, David Brownell wrote:
> On Thursday 14 May 2009, Zach Welch wrote:
> > If you are still willing continue in this role, I would like to see you
> > document the release processes (perhaps in doc/manual/releases.txt?) and
> > inform the rest of us what we need to do
On Thu, 2009-05-14 at 18:10 -0700, David Brownell wrote:
> On Thursday 14 May 2009, Zach Welch wrote:
> > I think that these links catapult The List
> > beyond a mere TODO or task list. It has started to provide references
> > to explain how the items got there in the first place, and I would lik
On Thu, 2009-05-14 at 17:41 -0700, David Brownell wrote:
> Alternatively, maybe the folk who now have responsibilities
>
> http://developer.berlios.de/project/memberlist.php?group_id=4148
>
> could start by saying how they see their roles, and what they
> see the process as being ... and what i
On Thursday 14 May 2009, Zach Welch wrote:
> >
> > Re "Why", IMO it might suffice to say that after four or five
> > months, lots of bugs have been fixed and features added, so
> > it's just time to clean up the rough spots and declare victory
> > over some stable code.
>
> I think the most press
On Thursday 14 May 2009, Zach Welch wrote:
> One point to make here is the conflicting desires of a "release manager"
> and "developers". At their extremes, the former would have us making
> stable releases every night, while the later would have us working madly
> on the trunk (and to heck with r
On Thu, 2009-05-14 at 19:57 -0700, David Brownell wrote:
> On Thursday 14 May 2009, Zach Welch wrote:
> > >
> > > Re "Why", IMO it might suffice to say that after four or five
> > > months, lots of bugs have been fixed and features added, so
> > > it's just time to clean up the rough spots and dec
On Thu, 2009-05-14 at 20:20 -0700, David Brownell wrote:
> On Thursday 14 May 2009, Zach Welch wrote:
> > One point to make here is the conflicting desires of a "release manager"
> > and "developers". At their extremes, the former would have us making
> > stable releases every night, while the lat
Hi all,
If anyone knows of patches that have not been applied, please reply here
with a link into the mailing list archives to the last version posted:
https://lists.berlios.de/pipermail/openocd-development/
If there are other issues to which the maintainers failed to respond,
please con
Zach Welch wrote:
> Hi all,
>
> If anyone knows of patches that have not been applied, please reply here
> with a link into the mailing list archives to the last version posted:
>
>
https://lists.berlios.de/pipermail/openocd-development/2009-May/006374.html
> https://lists.berlios.de/pipe
On May 14, 2009, at 1:39 PM, Zach Welch wrote:
Rick,
Following on my post about maintainer roles, I wanted to see if I
could
talk you into seizing the responsibilities and authority for the
release
process, with the particular mindset of getting us rolling toward
0.2.0.
I am willing to s
Where do I post bugs that I observe, but have no time to pursue?
Here is a bug that I have observed and kinda know the reason for:
proc foo{a} {
verify_image $a
}
# this will fail since command.c does not correctly create an overrideable proc
foo c:\\temp\\test.bin
#this works
verify_image
On Fri, May 15, 2009 at 3:10 AM, David Brownell wrote:
> On Thursday 14 May 2009, Zach Welch wrote:
>> I think that these links catapult The List
>> beyond a mere TODO or task list. It has started to provide references
>> to explain how the items got there in the first place, and I would like
>>
On May 14, 2009, at 11:03 PM, Øyvind Harboe wrote:
Where do I post bugs that I observe, but have no time to pursue?
Here is a bug that I have observed and kinda know the reason for:
proc foo{a} {
verify_image $a
}
# this will fail since command.c does not correctly create an
overrideabl
> Generally this is where a bug tracking system comes into play. Of course,
> as a community, we seem to be against that idea.
I think it's a matter of timing and we're nearing the point where it would
be *less* work for everybody if we had a bugtracking system.
--
Øyvind Harboe
Embedded softw
My interest lies in a couple of things. I don't know what
"role" this translates into though:
- recruit first rate maintainers. Actually I'm kinda done with this as
it seems we have a positive feedback loop now.
- commit good patches to svn quickly so as to encourage contributors
- keep an eye on
51 matches
Mail list logo
