On Monday 02 November 2009, Øyvind Harboe wrote:
> While the attached patch tightens things up, I don't think we've
> solved it just yet...
Looking more closely, this patch intoduced *TWO* bugs:
- The one causing the big regression, swapping physical
and virtual addresses for the work area:
How's this?
20 second timeout/megabyte
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From 1b60ce8d5badb730739744323cb7cd4ac6c252af Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?=
Date: Tue, 3 Nov 2009 15:3
bug: Fail to write to
Intel NOR Flash on AT91SAM9260
Pushed to master patch that inexplicably fixes the problem(improve
error handling and output for working area).
Hopefully once we track down the verify problem, we'll find the
real culprit
--
Øyvind Harboe
http://www.zylin.com/zy1000
Pushed to master patch that inexplicably fixes the problem(improve
error handling and output for working area).
Hopefully once we track down the verify problem, we'll find the
real culprit
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flas
On Tue, Nov 3, 2009 at 10:35 AM, Pieter Conradie
wrote:
> Hi Øyvind,
>
> Genius! The patch works :)
That makes no sense to me. Please post the debug_level 3 log...
> 0.3.0-rc0 with patch was able to successfully program and verify a 512k image.
>
> It is also able to succesfully program a 16 Mby
On Mon, 2 Nov 2009, David Brownell wrote:
> That is, "git describe efef05870d726fe4cb6786d785fae4628fe7ec1e"
> will tell you that it's 125 commits after the v0.2.0 tag.
BTW, when using that 40 character hex string, you can abbreviate it to
the first 7 or 8 characters. Git will accept it as long
On Monday 02 November 2009, Øyvind Harboe wrote:
> I don't know when 2646 was compared to 0.2... Don't know offhand
> how to check that w/git.
As I noted earlier: "git log", then use the search
mechanism to find "@2646" ... which points to:
> > That SVN id matches
> > efef05870d726f
If 2646 was pre 0.2 and I don't manage to fix this tomorrow, then
0.3 should go ahead.
I'd love to have this included in 0.3 though No pressure Pieter ;-)
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
_
2009/11/2 David Brownell :
> On Monday 02 November 2009, Pieter Conradie wrote:
>> ...
>> SVN2645: works
>> SVN2646: broken
>> ...
>> It appears that SVN2646 did break it.
>
> So this *is* a regression.
Maybe maybe not...
I was 100% convinced it was a regression in 2646, but the logs
from the two
On Monday 02 November 2009, Pieter Conradie wrote:
> ...
> SVN2645: works
> SVN2646: broken
> ...
> It appears that SVN2646 did break it.
So this *is* a regression. That SVN id matches
efef05870d726fe4cb6786d785fae4628fe7ec1e, also
known to "git describe" as v0.2.0-125-gefef058;
so it happened 12
1. NB! The svn version #'s listed in the git log do not match the svn
version #'s in the original repository. Going forward we should
stick to git for testing.
I assume you referred to the old svn version #'s in your testing?
2. I've tightened up the way working memory is
handled for the MMU enab
ubject: Re: [Openocd-development] openocd-0.3.0-rc0 bug: Fail to write to
Intel NOR Flash on AT91SAM9260
> SVN 2645: writes 512k to flash, verifies correctly
> SVN 2646: flash write_image fails with "timed out while waiting for target
> debug-running"
Hmm. this is trickie
On Friday 30 October 2009, Øyvind Harboe wrote:
> Is there a way to translate between svn and git version #'s?
First, stop using SVN numbers for new work.
But for cross referencing, "git log" will include the
SVN linear ID in the commits pulled via "git svn".
You can see one with e.g. "git show
2009/10/30 David Brownell :
> On Friday 30 October 2009, Pieter Conradie wrote:
>> It took me a while to set up an automated build process
>> so that I could do a SVN binary search. Here are the results:
>
> Good results ... but for the record, "git bisect" is
> a lot easier when you're doing a bin
On Friday 30 October 2009, Pieter Conradie wrote:
> It took me a while to set up an automated build process
> so that I could do a SVN binary search. Here are the results:
Good results ... but for the record, "git bisect" is
a lot easier when you're doing a binary search. :)
__
> SVN 2645: writes 512k to flash, verifies correctly
> SVN 2646: flash write_image fails with "timed out while waiting for target
> debug-running"
Hmm. this is trickier than I thought
Can you provide debug_level 3 logs for 2645 and 2646?
Try to use the *EXACT* same procedure so the logs
Well done! First rate testing!
> SVN 2646: flash write_image fails with "timed out while waiting for target
> debug-running"
I see that I broke run_algorithm when I fixed breakpoint handling...
I'll look into it.
This means the problem is not unique to arm926ejs and that it
is important to addr
t: Re: [Openocd-development] openocd-0.3.0-rc0 bug: Fail to write to
Intel NOR Flash on AT91SAM9260
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
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
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
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
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
23 matches
Mail list logo
