On Mon, Sep 14, 2009 at 8:35 AM, michal smulski wrote:
>
>
>> Did you also double check that 1822 breaks?
>>
> r1822 is broken without any mods. I did not try adding usleep() here but
> double-checked that it fails on memburst.
>
>
>
>> The burst code is executing two instructions to increment the
> Did you also double check that 1822 breaks?
>
r1822 is broken without any mods. I did not try adding usleep() here but
double-checked that it fails on memburst.
> The burst code is executing two instructions to increment the pointer. Perhaps
> the second instruction is getting executed twic
On Sun, Sep 13, 2009 at 11:26 PM, michal smulski
wrote:
> It does seem that this is a timing issue. However adding various
> usleep() around jtag.c and arm11_dbtap.c file does not produce errors on
> r1817. Also increasing TAP_IDLE's does not break the code.
Did you also double check that 1822 br
It does seem that this is a timing issue. However adding various
usleep() around jtag.c and arm11_dbtap.c file does not produce errors on
r1817. Also increasing TAP_IDLE's does not break the code.
It might be more productive to capture some of the data going to ft2232
interface. Is there a simple
> So r1817 passed but r1822 does not. r1817-r1821 do not compile.
>
> There are a lot of changes to jtag.c file here between r1817 - r1822.
> Anybody?
I've diffed 1817 and 1822 and I find nothing that could explain
arm11 burst writes failing. It's quite puzzling.
The only difference I could find
Ok,
Here is the script I run on various builds (svn 1504 - 1900)
init
halt
reset init
memwrite burst enable
load_image ./images/test.bin 0x8000 bin
verify_image ./images/test.bin 0x8000 bin
exit
Here are some results:
# svn 1600
#downloaded 88 byte in 0.008575s
#verified 88 bytes in 0.
No, the addresses with 0x0 do not get touched/written. I tested this by
first writing 'beefcafe' to all DDR2 memory addresses and then loading
image 'load_image' The 'beefcafe' was there on every other address like
0x0 in the previous test.
Michal
On Sat, 2009-09-12 at 10:53 +0200, Øyvind Harboe w
Øyvind Harboe schrieb:
>> So, every data word is written but at every other address.
>
> Not so quick! :-)
>
> Is 0 being written to every other address, or is every other address
> being written to?
>
> See this comment from the arm11 code:
>
> * The repeated TAP_IDLE's do not cause a repeat
> So, every data word is written but at every other address.
Not so quick! :-)
Is 0 being written to every other address, or is every other address
being written to?
See this comment from the arm11 code:
* The repeated TAP_IDLE's do not cause a repeated execution
* if passed without leaving
Could be an (ft2232) interface problem?
I'll try this on Monday hopefully on parport & ZY1000.
Did you try "tms_sequence long"
It's surprising that *reducing* the number of TAP_IDLE's fixes things...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
Here is what happens when I enable burst writes:
> load_image ./images/test.bin 0x8000 bin
Data transfer failed. (84)
use 'arm11 memwrite burst disable' to disable fast burst mode
Runtime error, file "command.c", line 473:
> memwrite burst disable
Disabled memory write burst mode.
> mdw
On Fri, Sep 11, 2009 at 8:22 AM, Øyvind Harboe wrote:
> On Fri, Sep 11, 2009 at 6:54 AM, michal smulski
> wrote:
>>
>> Attached:
>> 1. debug output for load_image without and with memburst write on
>> arm1136. See the slow load time on first and error on the other one.
>
> Try "help arm11" and t
On Fri, Sep 11, 2009 at 6:54 AM, michal smulski wrote:
>
> Attached:
> 1. debug output for load_image without and with memburst write on
> arm1136. See the slow load time on first and error on the other one.
Try "help arm11" and tinker with memrw_no_increment and
memwrite_error_fatal options.
If
13 matches
Mail list logo
