Hi,
There is a bug when using gdb to set read/write watchpoint.
OOCD will actually set a "write" watchpoint if you set "read" watchpoint
through gdb, and vis versa.
Since...
[target/breakpoints.h]
enum watchpoint_rw
{
WPT_READ = 0, WPT_WRITE = 1, WPT_ACCESS = 2
};
But...
[server/gdb_server.
>> > - Various ARMs should be enabling DCC downloads more often,
>> > for speed. (Not necessarily release-blockers...)
>>
>> What we agreed on doing here is to print out a warning if DCC
>> downloads + fast memory access were not enabled after reset.
>
> Sounds fair enough to me; for "after res
On 2010-01-11 07:29, Freddie Chopin wrote:
> a reset of JTAG
> "after power-up" issue
should be "a _REST_ of JTAG ..."
small typo
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinf
On 2010-01-11 04:46, David Brownell wrote:
> On Sunday 10 January 2010, Michel Catudal wrote:
>> I still have a problem with STM32 where the first load doesn't work.
>
> I don't remember seeing a description of such an issue ... can
> you post one, or an URL to a description in the mailing list?
D
On Sunday 10 January 2010, CeDeROM wrote:
> On Sun, Jan 10, 2010 at 10:35 PM, David Brownell wrote:
> > It's not in 0.4 but I've been looking at some of the infrastructure
> > work that's needed to incorporate it. Various non-mergeable patches
> > have been sent around.
> >
> > I'll post some mor
On Sunday 10 January 2010, Michel Catudal wrote:
> I still have a problem with STM32 where the first load doesn't work.
I don't remember seeing a description of such an issue ... can
you post one, or an URL to a description in the mailing list?
When you say "still", that suggests it's a problem
David Brownell a écrit :
> I'm sure there are a few issues other folk have been carrying
> around. Please share!
>
> - Dave
>
I spent a few hours today checking to see if I could see any issues with
the new code.
I still have a problem with STM32 where the first load doesn't work.
There is al
On Sun, Jan 10, 2010 at 10:35 PM, David Brownell wrote:
> It's not in 0.4 but I've been looking at some of the infrastructure
> work that's needed to incorporate it. Various non-mergeable patches
> have been sent around.
>
> I'll post some more later, but for now I see several areas that can
> wo
On Sunday 10 January 2010, Øyvind Harboe wrote:
> > (b) Øyvind's desire for an "erase_address" option to pad
> > to sector boundaries.
>
> This would be a new feature. If we have the ability to erase
> all sectors in an address range, we have no regression outstanding.
The issue is that the p
On Sunday 10 January 2010, CeDeROM wrote:
> Hello world! :-)
>
> What is the current support for SWD/SWJ in OpenOCD - is it going to be
> already available in 0.4.0 release? :-)
It's not in 0.4 but I've been looking at some of the infrastructure
work that's needed to incorporate it. Various non-
We(Zylin) have done some target testing, but have a couple
of targets lined up for this week.
We found a case where reset init worked from telnet, but failed
from gdb, we'll post when we're ready(possibly with a patch).
> (b) Øyvind's desire for an "erase_address" option to pad
> to sector b
On Sun, Jan 10, 2010 at 9:11 PM, Øyvind Harboe wrote:
> No. I think work might start in 0.5 timeframe, but a first release is
> probably 0.6/7'ish.
>
> Unless someone steps up and does some amazing work that is...
I see, thank you Øyvind! :-)
Best regards,
Tomek
--
CeDeROM, http://www.tomek.ce
On Sun, Jan 10, 2010 at 10:08 PM, CeDeROM wrote:
> Hello world! :-)
>
> What is the current support for SWD/SWJ in OpenOCD - is it going to be
> already available in 0.4.0 release? :-)
No. I think work might start in 0.5 timeframe, but a first release is
probably 0.6/7'ish.
Unless someone steps
Hello world! :-)
What is the current support for SWD/SWJ in OpenOCD - is it going to be
already available in 0.4.0 release? :-)
I have bought some voltage regulators (L6928D) for STM32Primer2 so now
I am prepared to test this functionality with no fear (unless 9 others
U17 get burned heheh). If y
On Sunday 10 January 2010, CeDeROM wrote:
> > So far I think RC1 has gone fairly well, suggesting we might
> > not need an RC2. But there have been no responses in the RC1
> > thread yet, so I might be missing important information.
>
> Maybe a short RC2 would verify integrity of the patches appl
On Saturday 09 January 2010, David Brownell wrote:
> Are there more issues that seem like they need attention before
> we freeze 0.4.0 ?
For the record, the most significant items now left on my own
list of stuff to do before freezing 0.4:
- That NOR "flash erase_address pad addr length" feature
On Sun, Jan 10, 2010 at 8:46 PM, David Brownell wrote:
> On Sunday 10 January 2010, CeDeROM wrote:
>> What will be next step after rc1 - a release or some short rc2?
>
> Not sure yet. I sent a post yesterday about RC1 status, and
> merging that FreeBSD buildfix knocks off one of the "to do"
> lis
On Sunday 10 January 2010, CeDeROM wrote:
> What will be next step after rc1 - a release or some short rc2?
Not sure yet. I sent a post yesterday about RC1 status, and
merging that FreeBSD buildfix knocks off one of the "to do"
list items, but there are more ... and I want to get feedback
from ot
On Sunday 10 January 2010, richard vegh wrote:
> Unfortunately I don't use git.
You don't need to use "git" to create usable patches. If
two trees are clean,
diff -NaurP tree1 tree2
will generate a better patch. (And if they're not clean,
it's mostly a case of trimming down the "diff"
It's easy, try this:
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
patch -p1 < filename.patch
git diff > gitpatch
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and fl
Unfortunately I don't use git.
Isn't it possible that you apply the changes with simple "patch -p1 <
filname.patch" on your working copy, then make a diff or commit it? The
lpc3180.c has the only file what has changed and 3 new files are added.
Richard
On Sun, Jan 10, 2010 at 8:27 PM, Øyvind Harb
"Is there a chance you could use "git diff"? I don't know if I'll
be able to apply and review this patch easily tomorrow...
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash program
Hello Dave!
On Sun, Jan 10, 2010 at 6:13 PM, David Brownell wrote:
>> #elif defined(__FreeBSD__)
>> HostOs = "FreeBSD";
>
> None of the other HostOS strings use anything except lowercase,
> so I merged an update that looks like this except that it sticks
> to lowercase there too ... no Camel
On Sunday 10 January 2010, CeDeROM wrote:
> Above I have already added new line definig new OS (neither "linux"
> nor "darwin" as it was proposed, but "FreeBSD" itself):
>
> #elif defined(__FreeBSD__)
> HostOs = "FreeBSD";
None of the other HostOS strings use anything except lowercase,
so I
Patch for:
- large page nand flash crash
- lpc3180 driver correction to accept lpc3180 select 0 mlc|slc commands
- 3 config files to support hitex lpc3250 usb stick
Hopefully it can be merged before 0.4.0 release.
Is this patch OK for you?
Richard
On Fri, Jan 8, 2010 at 10:38 AM, richard vegh
- Fix for building doxygen out of tree
Signed-off-by: Spencer Oliver
---
Doxyfile.in |2 +-
Makefile.am |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Doxyfile.in b/Doxyfile.in
index 519bb2f..f6e3ced 100644
--- a/Doxyfile.in
+++ b/Doxyfile.in
@@ -569,7 +569,7
Hello!
I have checked the issue with src/helper/command.c and I have one
comment - for my command.c file the #elif mentioned by Steve Franks is
located at line 1313..1332 (maybe I have other rc1 or file that was
generated for me looks a bit different) - to be specific it is about
this part of the
27 matches
Mail list logo
