> I don't have commit access so I'll email it to the list once I've got it put
> together.
Great!
The idea is that we can then have one release coordinator(Rick Altherr) and the
other committers pitch in as well.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG d
On Dec 1, 2008, at 11:20 PM, Øyvind Harboe wrote:
It sounds like there is agreement that we need a release
coordinator. Since
I haven't heard anyone jumping at the chance, I'll throw my name in.
Super!
Can you create a file in svn trunk with a list of things to be fixed?
I think we shoul
On Mon, Dec 1, 2008 at 11:28 PM, Kees Jongenburger
<[EMAIL PROTECTED]> wrote:
> The following patch moves defines in contrib/libdcc/dcc_stdio.c
> to make it compile again with non cortex targets. I Believe the code
> was not compiling.
>
> The patch also add__ARM_ARCH_5T__ as supposedly working tar
> It sounds like there is agreement that we need a release coordinator. Since
> I haven't heard anyone jumping at the chance, I'll throw my name in.
Super!
Can you create a file in svn trunk with a list of things to be fixed?
I think we should have a quality first, no time schedule policy and
a
I read through this tonight. Excellent work! The organization is
exactly what I was planning to do. The only suggestion I have is to
remove all the references to removed or deprecated syntax except for
the appendix. Otherwise it just confuses the issue. A first time
user shouldn't be e
On Dec 1, 2008, at 10:09 PM, Øyvind Harboe wrote:
Without such a person, the stability of the branch is at risk.
True.
But there also needs to be a consensus about what 1.0 should include.
"The person" could drive such a consensus of course.
--
Øyvind Harboe
http://www.zylin.com/zy1000.
On Dec 2, 2008, at 2:48 PM, Hiroshi Ito wrote:
+static void output_data(void)
+{
+ int i;
+ *gpio_data_register = output_value ^ INVERT_BITS;
+ for ( i = 0; i < 10; i++ )
+ ;
}
A for loop like that can't reliably be used as a delay loop. First,
the speed of th
What config file are you using when this happens? What host OS/
architecture are you using?
Rick
On Dec 1, 2008, at 10:14 PM, Kees Jongenburger wrote:
Hi
I am trying the run a drscan 0 32 0xa3002048 and I am getting a
SIGSEGV. Just posting here so you know :p
Program received signal SIGS
I was not able to apply this patch. Please create patch
against svn trunk and post again. Your first patch
applied fine, so do it in the same manner.
Also add yourself to the copyright at the top of ep93xx.c
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTA
Committed.
Thanks!
--
Ø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/mailman/listinfo/openo
On Dec 2, 2008, at 12:46 PM, Hiroshi Ito wrote:
I'm running openocd on EP9307(arm925t) CPU, as a HOST.
and target is EP9307 and ARM926t with EP9307 GPIO.
revision 1183 cause seg fault.
The problem is, cmd_queue_alloc returns unaligned pointer.
but it is used as a pointer to structure.
This pa
I'm running openocd on EP9307(arm925t) CPU, as a HOST.
and target is EP9307 and ARM926t with EP9307 GPIO.
this patch is,
1. speed up to usable speed.
nanosleep is too slow on my machine.
(linux is running 10mS timer, and I compiled openocd with uClibc.)
2. signal logic can be inverted with co
> > > I'm running openocd on EP9307(arm925t) CPU, as a HOST.
> > > and target is EP9307 and ARM926t with EP9307 GPIO.
> >
> > src/jtag/ep93xx.c is obviously broken.
> >
> > original author's way should be this.
>
> Sorry, it was a wrong patch.
> attchment is a good one.
Sorry, again.
forge
> > I'm running openocd on EP9307(arm925t) CPU, as a HOST.
> > and target is EP9307 and ARM926t with EP9307 GPIO.
>
> src/jtag/ep93xx.c is obviously broken.
>
> original author's way should be this.
Sorry, it was a wrong patch.
attchment is a good one.
Hiroshi Ito
Media Lab. Inc.,
> I'm running openocd on EP9307(arm925t) CPU, as a HOST.
> and target is EP9307 and ARM926t with EP9307 GPIO.
src/jtag/ep93xx.c is obviously broken.
original author's way should be this.
Hiroshi Ito
Media Lab. Inc.,
URL http://www.mlb.co.jp ( Sorry, Japanese only. )
TEL +81-3-5294-725
I'm running openocd on EP9307(arm925t) CPU, as a HOST.
and target is EP9307 and ARM926t with EP9307 GPIO.
revision 1183 cause seg fault.
The problem is, cmd_queue_alloc returns unaligned pointer.
but it is used as a pointer to structure.
This patch fix it. and it is working.
Index: src/jtag/jtag.
I haven't attempted to reproduce but I thought I would mention a few
things for those investigating. buf_set_buf() died because the passed
in src was bogus. That means the arg was wrong when buf_set_buf() was
invoked by jtag_build_buffer() at jtag.c:1228.
Rick
On Dec 1, 2008, at 1:14 PM
Kees Jongenburger wrote:
> Hi
>
> I am trying the run a drscan 0 32 0xa3002048 and I am getting a
> SIGSEGV. Just posting here so you know :p
>
I don't see anything obvious :-(
FYI -you should be able to specify "drscan TAPNAME 32 0xa3002048"
instead of the hard coded 0 above.
That was the i
Kees Jongenburger wrote:
> This patch provides an initial beaglebloard.cfg file up for inclusion/review.
>
1) Please review the new documentation.
http://openocd.berlios.de/doc/Config-File-Guidelines.html
2) In the "beagleboard.cfg"
+jtag newtap beagleboard jrc_icepick -irlen 6 -ircap
rick> Then you probably haven't seen 'make distclean' either
Oh I have - and things deep in the bowels of GDB and GCC In fact, I
have my own "googlewhack"
So that -it remains a google wack, I must spell it out... goto google
and type my name, the digit 1, a space, and the word y a i p.
Sometim
Oyvind> But there also needs to be a consensus about what 1.0 should
include.
Getting "consensus" is the best choice of action.
I think what we in the USA call - a "Laundry List"
A big list of things to do, you do not do them all.
You do the most pressing ones.
The important thing is
Oyvind> But there also needs to be a consensus about what 1.0 should
include.
Getting "consensus" is the best choice of action.
I think what we in the USA call - a "Laundry List"
A big list of things to do, you do not do them all.
You do the most pressing ones.
The important thing is
On Dec 1, 2008, at 3:41 PM, Duane Ellis wrote:
Theodore A. Roth wrote
I just did a 'make distcheck' on the 1.0 branch and it failed.
Thanks.
And I've used GNU and LINUX stuff since Slackware-95 - and I still to
this day - I come across stuff I had never seen before.
-Duane.
Theodore A. Roth wrote
>> I just did a 'make distcheck' on the 1.0 branch and it failed.
Thanks.
And I've used GNU and LINUX stuff since Slackware-95 - and I still to
this day - I come across stuff I had never seen before.
-Duane.
___
Openocd-deve
The following patch moves defines in contrib/libdcc/dcc_stdio.c
to make it compile again with non cortex targets. I Believe the code
was not compiling.
The patch also add__ARM_ARCH_5T__ as supposedly working target.
greetings
Index: contrib/libdcc/dcc_stdio.c
=
This patch provides an initial beaglebloard.cfg file up for inclusion/review.
1) I use it with the following configuration. and run into some problems:
I can not tun the enable_dap multiple times (note that is doesn't do anything
real strange)
2) As you see I defined "beagleboard" board. I see th
Hi
I am trying the run a drscan 0 32 0xa3002048 and I am getting a
SIGSEGV. Just posting here so you know :p
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f47fee1b6e0 (LWP 13122)]
0x0044dd1f in buf_set_buf (src=0xff00ff , src_start=0,
dst=0x70cfb0 "
> Without such a person, the stability of the branch is at risk.
True.
But there also needs to be a consensus about what 1.0 should include.
"The person" could drive such a consensus of course.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash p
On Dec 1, 2008, at 12:10 PM, Rick Altherr wrote:
There is never a good time to make a branch. That's why you choose
tools that allow easy merging between branches and the trunk. I
wouldn't say that the 1.0 branch was cut too early. It isn't
entirely clear that all of the changes committe
> But easy to rectify with a merge rather than recutting the branch. Also,
> just the commits related to the syntax changes can be merged in without
> taking all the other changes made to ToT. Just because the syntax changes
> should be taken for 1.0 doesn't mean everything else in HEAD should be
>
> Spen: Should we delete the 1.0 branch for now and cut a new
> one once it is time?
>
> Porting back from svn trunk makes little sense at this point
> since we have changed the syntax so much and I'd be very much
> against using the old syntax in the 1.0 release
>
> --
we could delete
On Dec 1, 2008, at 12:16 PM, Øyvind Harboe wrote:
There is never a good time to make a branch.
True, but there is such a thing as a bad time to make a branch.
Cutting the 1.0 release *before* we have the syntax changes in was/
is a
bad time.
--
Øyvind Harboe
http://www.zylin.com/zy1000
> There is never a good time to make a branch.
True, but there is such a thing as a bad time to make a branch.
Cutting the 1.0 release *before* we have the syntax changes in was/is a
bad time.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash p
On Dec 1, 2008, at 11:54 AM, Øyvind Harboe wrote:
Subversion makes it very easy to merge from trunk to branch. If
_all_ of
the changes made to trunk should be pulled into the branch, it can
be done
with 2 commands while recreating the branch takes 4. Someone
should review
the changes com
> Subversion makes it very easy to merge from trunk to branch. If _all_ of
> the changes made to trunk should be pulled into the branch, it can be done
> with 2 commands while recreating the branch takes 4. Someone should review
> the changes committed since the branch was made and make a list of
On Mon, Dec 1, 2008 at 8:37 PM, Theodore A. Roth <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 11:27 AM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
>> Is this broken in svn trunk?
>>
>> If it doesn't work in svn trunk, then, for sure, it won't work in the
>> 1.0 branch.
>
> Yes, it is broken in
On Mon, Dec 1, 2008 at 11:27 AM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
> Is this broken in svn trunk?
>
> If it doesn't work in svn trunk, then, for sure, it won't work in the
> 1.0 branch.
Yes, it is broken in trunk. Attached is a patch against trunk. Ignore
the previous patch since this one i
On Dec 1, 2008, at 11:27 AM, Øyvind Harboe wrote:
Is this broken in svn trunk?
If it doesn't work in svn trunk, then, for sure, it won't work in the
1.0 branch.
Spen: Should we delete the 1.0 branch for now and cut a new one once
it is time?
Porting back from svn trunk makes little sense
Is this broken in svn trunk?
If it doesn't work in svn trunk, then, for sure, it won't work in the
1.0 branch.
Spen: Should we delete the 1.0 branch for now and cut a new one once it is time?
Porting back from svn trunk makes little sense at this point since we
have changed the syntax so much an
Hi,
On Mon, Nov 24, 2008 at 3:24 AM, Spen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have created a release 1.0 branch:
> svn://svn.berlios.de/svnroot/repos/openocd/branches/openocd_1_0_branch
> if no major issues are found after say 1 month then we will tag a release.
>
> I can test the st/pic32 targ
On Mon, Dec 1, 2008 at 12:38 PM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Rick,
>
> I don't have an arm11 target to test with.
Hi I can test on an smdk6431
greetings
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists
On Dec 1, 2008, at 3:38 AM, Duane Ellis wrote:
Rick,
I don't have an arm11 target to test with.
I believe you have an ARM11 target... can you confirm the arm11
still works after my changes?
[or anybody else out there who has one...]
-Duane.
I've never tried using OpenOCD against my c
> That is exactly my point!
>
> My goal: A rule of thumb for the new "Guide Lines" section. Pedantic target
> script writers can be as pedantic as they want to be.
There is a src/target/target/readme.txt that is started.
The idea is that a good target script has expectations that it should
live u
duane> [long description of how to do this]
kees> The kind of changes you are talking about seams very far away from
anything I could help with.
duane> That's ok - feed back & testing is also very helpful.
Kees, (and other Beagle Board Types)
SVN version r1194 - should have enough commands and
Rick,
I don't have an arm11 target to test with.
I believe you have an ARM11 target... can you confirm the arm11 still
works after my changes?
[or anybody else out there who has one...]
-Duane.
___
Openocd-development mailing list
Openocd-developmen
Spen/Oyvind,
{or somebody else...}
Can one of you help me with the str9 issues?
I'm sort of stuck.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Sorry - these quotes are snipped & quite out of order..
rick> That isn't true for at least the Stellaris flash code.
rick> I don't know the other drivers very well,
Example: The AT91SAM7 flash drives require 0.
rick> We should be more explicit than just saying "1K minimum."
Øyvind> It is a kn
Øyvind> If the issues relate [snip] a problem we'll be fixing in
[snip] 3-6 months,
Øyvind> [dcc] It's only 24 bytes, what's the downside?
(A) Good: If enabled, aligned, and (size >128 byte) DCC use is automatic.
(B) Missing: There is no protection for over-writing it self
(C) Missing: There i
Øyvind> I seem to recall a JTAG debugger that stopped GDB on the
instruction that caused the a memory fetch abort.
The EPI Tools "Majic" I used did exactly that. I believe the JENIE did
so too. I would expect the ARM box does this now.
This would be *FANTASTIC*. All it has to do is - when the v
49 matches
Mail list logo
