Hi ,
On Fri, Oct 30, 2009 at 2:23 AM, zzzh.2007 wrote:
> Hi, all
>
> For FA526 core, following bugs exist:
> 1. after i make a step(in openocd-0.3.0-rc0) at reset vector(which is LDR pc
> 0x5c),
> the pc did not skip to 0x5c, but to 0x04, and then to 0x08...
> 2. I still can't step or set br
On Fri, Oct 30, 2009 at 7:19 AM, Dimitar Dimitrov wrote:
> On Sunday 25 October 2009, you wrote:
>> If you could report back on whether software breakpoints
>> work in memory marked as read only by the MMU that
>> would be fantastic.
>
> Where can I find an example application that enables the MMU
On Sunday 25 October 2009, you wrote:
> If you could report back on whether software breakpoints
> work in memory marked as read only by the MMU that
> would be fantastic.
Where can I find an example application that enables the MMU and marks code
regions as read only?
Dimitar
__
Hi, all
For FA526 core, following bugs exist:
1. after i make a step(in openocd-0.3.0-rc0) at reset vector(which is LDR pc
0x5c), the pc did not skip to 0x5c, but to 0x04, and then to 0x08...
2. I still can't step or set break point in insight.
--
On Thursday 29 October 2009, Dimitar Dimitrov wrote:
> I fixed the issue by disabling dcc memory uploads.
Bizarre. Disabling those let the initial enumeration
work at full speed?? Or was that caused by some other
patches in your repository?
Is this still with adaptive clocking enabled?
Where d
On Thursday 29 October 2009, Zach Welch wrote:
> On Thu, 2009-10-29 at 03:05 -0700, David Brownell wrote:
> > On Wednesday 28 October 2009, Zach Welch wrote:
> > > I just tagged 0.3.0-rc0 and will post the packages shortly.
> >
> > Great! Thanks. I don't think anyone's going to
> > object to thi
Uhh... I forgot to check the log. It does appear like a ft2232 problem...
The symptoms are very much like that other bug though: dcc failing...
Error: 627 36721 ft2232.c:370 ft2232_write(): ftdi_write_data: usb
bulk write failed
Error: 628 36721 ft2232.c:672 ft2232_send_and_recv(): couldn't writ
Please check if you are in fact seeing this problem:
https://lists.berlios.de/pipermail/openocd-development/2009-October/011760.html
Disabling dcc, just means that you have identified that the
bug is in the dcc memory write(s). dcc memory writes are
*much* faster than the alternatives, so we hav
Michael is right, this patch should fix the issue.
2009/10/30 David Brownell
> On Thursday 29 October 2009, Michael Roth wrote:
> > The code works like follow (N = bit_len):
> >
> > N -1 %4 2<< -1 ~ (binary)
> > ---
I fixed the issue by disabling dcc memory uploads. Otherwise my setup hasn't
changed:
1. Openocd fetched from latest GIT
2. libftdi-0.16 from the latest release tarball
3. FT2232 timeout/retry-count patch applied (attached).
4. ARM-USB-TINY-H interface config (attached)
After starting openocd I
On Thursday 29 October 2009, Freddie Chopin wrote:
> 1. When using lpc2103.cfg or stm32.cfg (probably many other target
> scripts) when started OpenOCD warns:
>
> > Warn : use 'lpc2103.cpu' as target identifier, not '0'
>
> which is because lines like:
>
> > flash bank stm32x 0 0 0 0 0
>
> wh
On Thursday 29 October 2009, Øyvind Harboe wrote:
> If rebase can't merge reordering of code automatically,
It won't. But on the other hand, pure reordering won't
generally create particularly painful merge issues. (It's
merge tool confusion which does that.)
When I do such things by hand, it's
On Thu, 29 Oct 2009, Øyvind Harboe wrote:
> How's this branch btw? (comments, signoff, etc.)
>
> It's where I exercise my rebase skills :-)
>
> http://repo.or.cz/w/openocd/oharboe.git?a=shortlog;h=refs/heads/mrcmcr
You're making progress!
One example where improvements could be made though:
h
>> More generally: does anyone have a great reference to
>> git branches, rebase & automatically refactored java code?
>>
>> (This would include name changes of classes, extracting methods,
>> rename of files, etc.)
>
> If you really want to strive into academic topics, you may try to
> implement
On Thursday 29 October 2009, Freddie Chopin wrote:
> 2. When using stm32.cfg OpenOCD says (beside the above):
>
> > Warn : stm32.bs: nonstandard IR mask
>
> which is because of
>
> > jtag newtap $_CHIPNAME bs -irlen 5 -ircapture 0x1 -irmask 0x1
> > -expected-id $_BSTAPID1 -expected-id $_BSTA
On Thu, 29 Oct 2009, Øyvind Harboe wrote:
> Maybe I'm using rebase incorrectly, but when code is reordered
> (to avoid declarations to resolve forward references), then a
> rebase will not run without requiring manual merging.
Exact.
> If rebase can't merge reordering of code automatically, then
On Thu, Oct 29, 2009 at 8:45 PM, Nicolas Pitre wrote:
> On Thu, 29 Oct 2009, Øyvind Harboe wrote:
>
>> If the particular issue above is caught red-handed we'll
>> be able to evaluate whether or not we have something
>> which is optimized too much for marginal speed gains
>> and too little for stab
On Thursday 29 October 2009, Pavel Kurochkin wrote:
> May be somebody tried to communicate with such hardware (PXA320
> or NAND flash).
I don't see any PXA flash driver in src/flash, so I'm
guessing not ... the earlier generations of PXA hardware
tended to use NOR/CFI flash.
But you're asking in
On Thu, 29 Oct 2009, Øyvind Harboe wrote:
> If the particular issue above is caught red-handed we'll
> be able to evaluate whether or not we have something
> which is optimized too much for marginal speed gains
> and too little for stability...
The work area is used for far more things than just
On Thursday 29 October 2009, Wookey wrote:
>
> > CUT HERE
> > Preliminary implementation of XSVF support for detailed
> > state path transitions.
>
> Well, my part in that was much easier than I expected, and you sir,
> are a genius :-)
I wouldn't go that far ... but feel free to fe
On Thursday 29 October 2009, Michael Roth wrote:
> The code works like follow (N = bit_len):
>
> N -1 %4 2<< -1 ~ (binary)
> --
> 1 0 0 2 1 1110
> 2 1 1
Maybe I'm using rebase incorrectly, but when code is reordered
(to avoid declarations to resolve forward references), then a
rebase will not run without requiring manual merging.
If rebase can't merge reordering of code automatically, then I
would generally like such pervasive refactoring of code
On Thu, Oct 29, 2009 at 7:58 PM, Nicolas Pitre wrote:
> On Thu, 29 Oct 2009, Øyvind Harboe wrote:
>
>> In OpenOCD there is a bit of clever handling of working areas.
>>
>> You can essentially allocate a piece of working memory on the target and
>> store e.g. an algorithm into that working area ove
On Thu, 29 Oct 2009, Øyvind Harboe wrote:
> In OpenOCD there is a bit of clever handling of working areas.
>
> You can essentially allocate a piece of working memory on the target and
> store e.g. an algorithm into that working area over an extended period
> of time to improve performance.
>
> I
OpenOCD 0.3.0-rc0 compiled on mingw with ftd2xx.dll
1. When using lpc2103.cfg or stm32.cfg (probably many other target
scripts) when started OpenOCD warns:
> Warn : use 'lpc2103.cpu' as target identifier, not '0'
which is because lines like:
> flash bank stm32x 0 0 0 0 0
which should be
> fl
Hi David,
Thank you for submitting this patch! The support for Signalyzer H
compiles and runs fine.
I like your idea about ctrl_write() returning negative numbers for
D2XX as well, I will make the changes, it will indeed reduce amount of
#ifdef.
Best regards,
Oleg
---
www.signalyzer.com
On Tu
In OpenOCD there is a bit of clever handling of working areas.
You can essentially allocate a piece of working memory on the target and
store e.g. an algorithm into that working area over an extended period
of time to improve performance.
If a reset or similar happens, then OpenOCD will iterate t
Hello everybody!
We develop devices for measurement purposes in telecommunications.
And we are currently investigating new hardware platform based on
Marvell pxa320 cpu.
We got developement boards from Toradex company: Colibri PXA320 and Orchid
carrier board for it. But that boards has preinstal
On Thu, Oct 29, 2009 at 3:02 PM, Øyvind Harboe wrote:
> On Thu, Oct 29, 2009 at 2:11 PM, Pieter Conradie
> wrote:
>> Hi Øyvind,
>>
>> 1. OpenOCD SVN 732 works. OpenOCD 0.2.0 does not work.
>
> Can you bisect it further? We know it broke between 788 and 732.
I've gone over the changes between 788
+++ David Brownell [2009-10-27 19:17 -0700]:
> On Tuesday 27 October 2009, Wookey wrote:
> > > So if I whack together a patch turning XSVF's (c) into
> > > the (b) which is supported, you could test it and maybe
> > > fix any goofs?
> >
> > Yes, I think so (fighting chance at least).
>
> Alrighty
On Thu, Oct 29, 2009 at 2:11 PM, Pieter Conradie
wrote:
> Hi Øyvind,
>
> 1. OpenOCD SVN 732 works. OpenOCD 0.2.0 does not work.
Can you bisect it further? We know it broke between 788 and 732.
From TODO:
- regression: "reset halt" between 729(works) and 788(fails): @par
https://lists.berlios.d
The code works like follow (N = bit_len):
N -1 %4 2<< -1 ~ (binary)
--
1 0 0 2 1 1110
2 1 1 4 3 1100
3 2
>I need to find out which pin on my board the chip's uart rx line is
connected to. My chip is a s3c2410 (arm920t).
>I can connect through jtag and execute openocd commands. Is there any
way to get some output on a certain pin of the chip >through jtag?
Something boundry-scan like that I can then pr
I need to find out which pin on my board the chip's uart rx line is
connected to. My chip is a s3c2410 (arm920t).
I can connect through jtag and execute openocd commands. Is there any way to
get some output on a certain pin of the chip through jtag? Something
boundry-scan like that I can then probe
And of course the compulsory question:
can you find a version of OpenOCD where this worked?
A bisection would be even better!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openo
On Thu, 2009-10-29 at 03:05 -0700, David Brownell wrote:
> On Wednesday 28 October 2009, Zach Welch wrote:
> > I just tagged 0.3.0-rc0 and will post the packages shortly.
>
> Great! Thanks. I don't think anyone's going to
> object to this milestone being "rc0" not "rc1",
> although it's a somewh
You can also try disabling fast memory access.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.
Does anyone have an at91sam9260 that they could donate to us?
1. Try to remove "-work-area-backup 1"...
2. Try disabling dcc downloads (giving up on dcc downloads
will reduce performance...).
It's actually the write of 2048 bytes to RAM that crashes as it uses
dcc(?) downloads
and it's the dcc
Hi, all
Thanks Zach, i'd downloaded openocd-0.3.0-rc0 with his help.
I'd compiled it and it's runing now running on my pc.
For FA526 core, following bugs exist:
1. after i make a step(in openocd-0.3.0-rc0) at reset vector(which is LDR pc
0x5c), the pc did not skip to 0x5c, but to 0x04, and the
On Wednesday 28 October 2009, Zach Welch wrote:
> I just tagged 0.3.0-rc0 and will post the packages shortly.
Great! Thanks. I don't think anyone's going to
object to this milestone being "rc0" not "rc1",
although it's a somewhat unusual naming convention.
Could you elaborate on what you're usi
I'll look into this issue tomorrow.
2009/10/29 David Brownell
> On Wednesday 28 October 2009, FangfangLi wrote:
> > Dear Sir:
> >
> > for the bellow statement:
> > SDR 3 TDI (5) TDO (2);
>
> That's sneaky ... including a test report with a bug report!
>
>
> > In function :svf_copy_hexstring_to
Thanks for taking the lead on this David!
If you could be responsible for tagging release candidates
and releases(0.3 and on...), then we can sort out creating
release packages, branches, etc. later.
I'm pretty sure that Zach's scripts allow using a tag to produce a
release?
--
Øyvind Harboe
ht
42 matches
Mail list logo
