it should be a seperate project.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Can one of you help me with the str9 issues?
I'm sort of stuck.
I have had a quick look - very broken.
I will see if i can get to the problem.
trunk is now working with the str9xpec driver.
I am going to add a some info in the docs on its correct use.
Cheers
Spen
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
Hi,
Committed the following:
- stm32x flash driver: add support for low density devices
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
committed the attached patch:
- fix issue with luminary flash driver and tail bytes
This is already done in other flash drivers
Index: src/flash/stellaris.c
===
--- src/flash/stellaris.c (revision 1190)
+++
Found a couple of issues with the targets cmd
fixes seg fault with multiple targets and fixes printing the target names.
Cheers
Spen
Index: target.c
===
--- target.c(revision 1186)
+++ target.c(working copy)
@@ -1362,7
this info.
Also you get acks back from the swi so speed does not matter as the clock is
in sync, similar to the old jtag rclk.
Also in future we could add support for the trace port - similar to old arm
etm.
Cheers
Spen
___
Openocd-development mailing list
It is common practice for an open-source project to release a
version as a tar of the source code. I expect we will
release a source code tar, linux binaries, and win32 binaries.
That's my thinking.
Spen
___
Openocd-development mailing list
.
--
Rick Altherr
[EMAIL PROTECTED]
Depends on the general consensus - i still use/like the old syntax.
But i am not averse to change.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de
(month or so) all is good then we tag a release 1.0.
This will have no effect on mainline svn (trunk) - this will progress as
normal.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman
i said before we will only add major bug fixes to this release branch,
svn trunk will continue as normal.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
spen release will be for both x86 win32 (mingw) and linux
I would add a Cygwin build.
Only because - often some development environments are
_cygwin_ in addition to mingw
Fair enough - easily done.
Spen
___
Openocd-development mailing list
Hi,
you need to be using the main openocd trunk for cortex_m3 support - the
cortex_m3 branch was for early dev work.
http://svn.berlios.de/svnroot/repos/openocd/trunk
You also need to increase the working area to at least 16k
Cheers
Spen
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL
Hi,
I have committed the attached patch.
It adds hardware breakpoint support to the mips target.
TODO: software breakpoints and watchpoints.
Cheers
Spen
mips.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development
Cheers
AndyP
Hi Andy
Think this is the wrong project - looks like this patch is for urjtag.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd
Hi,
committed the following patch.
It stops multiple calls to examine from allocating the breakpoint arrays
etc.
Cheers
Spen
Index: cortex_m3.c
===
--- cortex_m3.c (revision 1168)
+++ cortex_m3.c (working copy)
@@ -1357,50
FYI - contains some good info
http://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2
pdf
http://www.embecosm.com/appnotes/ean3/embecosm-howto-gdb-porting-ean3-issue-
2.pdf
Cheers
Spen
___
Openocd-development mailing list
Openocd
Hi,
I have committed the following mips patch.
It corrects a register hi/lo read - wrong way round
all the register now can be written to, including the special CP0 regs.
I will have a look at the breakpoint support - hopefully.
Cheers
Spen
mips.patch
Description: Binary data
/write
routines need improving aswell.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Hi,
committed a small patch that fixes a crash when the mips variant is not
specified.
Cheers
Spen
Index: mips_m4k.c
===
--- mips_m4k.c (revision 1159)
+++ mips_m4k.c (revision 1160)
@@ -234,6 +234,7 @@
{
mips32_common_t
you are quite correct, as a workaround replace the backslashes with forward
slashes.
other than that the tcl developers will give you a more definitive
answer/fix - have to admit it, but i am lost when it comes to that part of
openocd now.
Cheers
Spen
_
From: [EMAIL PROTECTED]
[mailto
than accepting it?
I did have similar problems with an older gdb turned out after further
debugging the problem was caused by ld
are there still issues when using gdb directly, rather than through gdbmi.
Cheers
Spen
___
Openocd-development mailing list
Hi,
I have committed this patch -it fixes issues with newer gcc and native
win32 builds where gettimeofday does not exist.
Cheers
Spen
Index: replacements.h
===
--- replacements.h (revision 1100)
+++ replacements.h
though
openocd.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Not looked into this patch but may give you some ideas
http://developer.berlios.de/patch/?func=detailpatchpatch_id=1462group_id=4
148
Cheers
Spen
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of John McCarthy
Sent: 17 October 2008 23:01
In spens case, yes, I think something did change.
I think SPEN is thinking reset - plain - halts the CPU.
But it does
not - it does reset run.
I think that decision - which happened about 1 month ago -
was perhaps
a bad choice (there was lots of email about that flying
This makes it possible for flash fill to modify part of a
sector. Erase can still be invoked seperately and explicitly.
Did not even realise we had a flash fill function!
Could be worth adding something to the docs.
Cheers
Spen
___
Openocd
Did not even realise we had a flash fill function!
Could be worth adding something to the docs.
Help already exists...
Could i ask where ?
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https
,
fill with
pattern address byte_pattern count);
But we still need to keep the texi in sync, otherwise how do new (or old)
users learn about new commands
Cheers
Spen
___
Openocd-development mailing list
Openocd-development
then the script gets called.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
and reformat
the spaces to tab chars.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Not sure what to make of this one - the same code is pretty much used in the
arm4_5 handling.
so that probably needs checking aswell.
I am guessing but it looks like the arch_type of reg_t is causing the
initial problem.
also i struggle to understand why it has only appeeared now!!
Cheers
Spen
to work reliably.
cortex does not support RCLK, and is not recommended by arm todo so.
If the jtag clock is to fast you will receive a SWJ-DP OVERRUN.
The best overall solution is to support SWD rather than jtag as the error
reporting is much better from the debug interface.
Cheers
Spen
Great approach good work!
Committed.
Once testing results are in and all quirks are weeded out the
old driver will be retired.
I have reformated/commited this patch to replace any lf's with tabs.
Cheers
Spen
___
Openocd-development
issues) from aduc driver and cleanup
- updated docs for aduc702x flash driver
Cheers
Spen
aduc702x.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo
'
Warning:BUG: keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (2032)
also had a quick look but i think all this help stuff is tcl now - so unsure
how all this works now.
Cheers
Spen
___
Openocd-development mailing list
Openocd
Hi,
Just to keep you all informed - i have committed a patch that adds me to the
files i have added
major contributions for over the years.
Looking at the logs my first patch was in dec 2005 - how time flies !!
Cheers
Spen
___
Openocd-development
parts. It will be fixed starting with Fury Rev B, DustDevil Rev B, Tempest
(next part).
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Committed.
I am struggling to see what gain this patch has brought (unless i have
missed something) - you are still calculating the checksum.
you have just moved inline code to a inline function !!
Cheers
Spen
___
Openocd-development mailing
understand that bit, but why move the code into a inline function?
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
What version of GDB do we need to test this?
CVS HEAD?
yes cvs head was used.
This is the link to the original gdb patch:
http://sourceware.org/ml/gdb-patches/2008-07/msg00152.html
Cheers
Spen
___
Openocd-development mailing list
Openocd
Hi,
I have committed this patch that fixes the broken gdb extended remote
protocol.
simply clears all breakpoints/watchpoints before resetting the target.
the gdb start command now works as expected.
Cheers
Spen
gdb restart.patch
Description: Binary data
to implement a vasprintf
in replacements.c
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
are using.
I used the Explrer 16 (DM240001) with the pic32 plugin MA320001.
Mainly because it has the jtag connector onboard.
But any others should work as long as you can access the jtag pins.
Cheers
Spen
___
Openocd-development mailing list
Openocd
@@
wp_type = WPT_READ;
else if (type == 4) /* access watchpoint */
wp_type = WPT_ACCESS;
+
+ if
(gdb_breakpoint_override((bp_type==BKPT_SOFT)||(bp_type==BKPT_SOFT)))
guessing this is a typo ??
Cheers
Spen
it compile under MinGW and wait
for the file event stuff to be handled in the jim devel mailing list.
just committed the attached patch that fixes the win32 (mingw) build
still builds ok under cygwin and linux
Cheers
Spen
jim-eventloop.patch
Description: Binary data
Hi,
I have committed the attached patch.
It removes a few more build warnings.
fixes broken mips build - unsure when this happened.
fixes non working --enable-gccwarnings configure option.
added --enable-gccwarnings to docs.
Cheers
Spen
warnings.patch
Description: Binary data
programming in
gdb.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
this, should be able to update to
standard autotools.
could you give me your configure line and i will try and fix.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd
tcl.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
saved_reset: no such variable
In procedure 'reset' called at file ?, line 1
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
the like the old functionality by the minute.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
then that wasn't possible before and isn't possible now :-)
it sure was last time i tried it about 2months or so ago with a str75x and
stm32 on the same chain.
if i remember correctly i was using run_and_halt but it still worked.
Cheers
Spen
to
halt, the code you are writing could be buggy.
The last thing you want is it running.
Like i said previously we could configure what globally a reset did, now we
cannot - unless we use tcl.
Cheers
Spen
___
Openocd-development mailing list
Openocd
and jim_mem2array need moving from
target.c
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
on general consensus from the other
dev's.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
it
without using the commandline.
A possible solution is to pass the reset option to daemon_startup, but then
we might have well kept the old code.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https
You can also add init and reset halt to the end of the
config script if you want.
If this is the case then ok, i was not aware you could do this.
However all the target scripts that were using reset_halt should really be
changed to give the same behaviour.
Cheers
Spen
Subject: [Openocd-development] cortex m3 - breakpoints
Hmm, something does not work with the cortexm3 breakpoints.
The problem is caused by the target_resume function, try svn head now
Cheers
Spen
___
Openocd-development mailing list
Openocd
be reset_halt, not
reset_init.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
and breaks straight away - unsure of a
clean way of catching this.
I will look into it more tomorrow.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
target.c:741 target_call_event_callbacks(): target event 0
Debug: 176 1000 command.c:397 command_run_line_internal(): script
debug.script
Had a quick look, but i find debugging the tcl stuff a real pain.
Cheers
Spen
___
Openocd-development mailing list
early silion does not have the electronic
signature programmed.
This happened on the medium density aswell - but effected very few.
you may have to do all the testing, all the high density parts i have are
ok.
I think i answered you on the st forum aswell.
Cheers
Spen
stm32.patch
Description
of that.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
it
alone.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
/commands.tcl.
An idea is to embed the minimum required tcl scripts into openocd, so it as
such appears standalone.
Other tcl scripts can still be added to the tcl dir to add functionality,
but these are not a requirement for openocd to function.
Cheers
Spen
?
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
area set.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Hi,
Just added the svn props for the recently added files.
Also fixed the strange line endings in commands.tcl
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
few reset scripts call
soft_reset_halt
soft_reset_halt is the only function that will clear the cpu regs.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
committed
Many Thanks
Spen
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonas
Horberg
Sent: 25 June 2008 09:56
To: openocd-development@lists.berlios.de
Subject: [Openocd-development] [PATCH] ARM7 reset_halt fix
Hi list,
I had a problem with the reset_halt mode
71 matches
Mail list logo
