On Wed, Mar 23, 2011 at 2:06 PM, Drasko DRASKOVIC
<drasko.drasko...@gmail.com> wrote:
> Hi Andy,
> are you using big or little endian CPU ?
big endian.
>
> Is mips32_pracc_fastdata_xfer() function called, and does it succeeds,
> or it falls back to simple mips_m4k_write_memory() ?
I realized I had not setup the working area properly and having done
so load_image is much faster (14.378 kb/s)
However I have noticed other problems, to give some background the
board is a mips router which already has a working factory firmware, I
am trying to port the uboot code released by the manufacturer into a
newer version of uboot, so I load my new uboot binary into memory and
resume to that address, but instead of running my code the system
seems to reset and boot from rom again.
So I tried a more simple binary which simply toggles a gpio to make a
led flash, but the same thing happens.
Here is a log with some notes.
> targets
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* xway.cpu mips_m4k big xway.cpu running
*At this point the board has loaded uboot from rom and is at the uboot prompt.
> halt
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0x83fd7ac0
> load_image test1 0x80000000
57344 bytes written at address 0x80000000
downloaded 57344 bytes in 3.937115s (14.224 kb/s)
> step 0x80000000
target state: halted
target halted in MIPS32 mode due to single-step, pc: 0x83fd7abc
*As you can see PC is not where I asked it to go.
> resume
*At this point the uboot prompt starts responding to input again,
showing that the system never exec any of my code.
> halt
> resume 0x80000000
*System resets and boots from rom.
Andy
>
> BR,
> Drasko
>
> On Tue, Mar 22, 2011 at 2:20 PM, Andrew Lyon <andrew.l...@gmail.com> wrote:
>> Hi,
>>
>> I am using a ft2232 based jtag device with a mips board and the
>> performance is really terrible:
>>
>> 57344 bytes in 3119.897949s (0.018 kb/s)
>>
>> It seems to work ok in that I can halt, resume, read/write memory etc,
>> but every operation is very slow, halting takes almost 3 seconds.
>>
>> I pulled the code from git and have tried using both libftdi and
>> libftd2xx0.4.16 but there is little difference.
>>
>> The jtag came with a guruplug and although I no longer have the
>> guruplug itself I do recall reflashing the 225k uboot image and it
>> took only a few seconds.
>>
>> Is this expected performance? If not what do I need to do to debug?
>>
>> Andy
>> _______________________________________________
>> Openocd-development mailing list
>> Openocd-development@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/openocd-development
>>
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
