Hi Drasko,
Hi Andy,
thank you for these tests, it is very helpful. The problem you have
can be easily solved by applying David Claffey's patches.
I see that mips32_pracc_fastdata_xfer() works well for you - I'll
take a look why it does not work for me and elaborate on the list.
Also, I can see that you are not facing the problem which I have :
Error: couldn't read enough bytes from FT2232 device (0 < 5)
Error: couldn't read from FT2232
Error: register read failed
Since Laurent from Amontec is capable of reproducing the same problem,
it might be something related to Amontec dongle I am using, but there
is small chance.
I did not reproduce your trouble, but we already see "couldn't read
enough bytes from FT2232 device ", when we started with the JTAGkey-2
(FT2232H), but is was coming from a too old driver, bugged with the
FT2232H part.
But this should not be your trouble, since you work with updated drivers.
Also, the JTAGkey-2 is not your trouble since everything else is stable
for you (other target board ... jtag chain detection ...), and since you
do not use RTCK ...
Question:
----------
Do you run openocd on 64bits or 32bits host machine ?
( Amontec Team is seeing some troubles with 64bits host machine running
openocd this week , STM32 flash error and others errors.
Regards,
Laurent
http://www.amontec.com
Which dongle are you using ?
Best regards,
Drasko
On Fri, Mar 25, 2011 at 11:52 AM, Andrew Lyon <andrew.lyon at gmail.com
<https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote:
>/ On Thu, Mar 24, 2011 at 11:01 AM, Drasko DRASKOVIC
/>/ <drasko.draskovic at gmail.com
<https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote:
/>>/ Hi Andy,
/>>/ I am very surprised that OpenOCD works for big endian MIPS.
/>>/
/>>/ I am currently working on this and I am preparing the patch that will
/>>/ fix some of the issues.
/>>/
/>>/ What I currently observed is :
/>>/
/>>/ 1) mips_m4k_write_memory() and mips_m4k_read_memory() do not handle
/>>/ endianess at all. Since these functions are used by mww and mdw
/>>/ commands to set up SDRAM controller, most probably your configuration
/>>/ is wrong. Can you check this by reading SDRAM controller configuration
/>>/ registers and comparing to that configuration you expect ? I'd be very
/>>/ suprised that it works.
/>>/
/>>/ 2) Only mips_m4k_bulk_write_memory() handles endianess, but it is
/>>/ called on 128 byes blocks (becaus it uses FASTDATA, and size of
/>>/ FASTDATA area is 16 words). Bottom line is that by my observation
/>>/ confirmed that mips32_pracc_fastdata_xfer() called internaly does not
/>>/ work either, and I do not think that it works for little endian
/>>/ targets also, missing some FASTDATA instructions. So, it would be very
/>>/ important if you can answer us the question I asked in the first mail
/>>/ : is mips32_pracc_fastdata_xfer() function called, and does it
/>>/ succeeds, or it falls back to simple mips_m4k_write_memory() ? I would
/>>/ expect to fail and fallback to mips_m4k_write_memory(), which as I
/>>/ explaind, do not handle endianess at all.
/>>/
/>>/ So please send us the report on following 3 things :
/>>/ 1) Is SDRAM configured OK (i.e. does mww commands work well for you)
/>/
/>/ Hi Drasko,
/>/
/>/ You are absolutely right there are endianness issues with mips
/>/ bigendian, on the board I am using the memory controller is already
/>/ configured by the onboard firmware but reading back the values I can
/>/ see they are bitswapped:
/>/
/>/ mdw 0xbf8011d0 1
/>/ 0xbf8011d0: 932d0000
/>/ Correct Value: 0xbf8011d0 0x2D93
/>/
/>/ mdw 0xbf8011e0 1
/>/ 0xbf8011e0: 35820000
/>/ Correct Value: 0xbf8011e0 0x8235
/>/
/>>/ 2) Is mips32_pracc_fastdata_xfer() exiting with error
/>/
/>/ No, I checked the debug logs and it works successfully:
/>/
/>/ Debug: 219 25550 target.c:1251 target_write_buffer(): writing buffer
/>/ of 57344 byte at 0x86000000
/>/ Debug: 220 25550 mips_m4k.c:984 mips_m4k_bulk_write_memory(): address:
/>/ 0x86000000, count: 0x00003800
/>/ Debug: 221 25551 target.c:1072 target_alloc_working_area(): MMU
/>/ disabled, using physical address for working memory 0xa0600000
/>/ Debug: 222 25551 target.c:1134 target_alloc_working_area(): allocated
/>/ new working area at address 0xa0600000
/>/ Debug: 228 28508 mips32_pracc.c:971 mips32_pracc_fastdata_xfer():
/>/ mips32_pracc_fastdata_xfer using 0xa0600000 for write handler
/>/
/>/ Debug: 230 28711 ft2232.c:1685 ft2232_execute_scan(): ft2232 buffer
/>/ size reached, sending queued commands (first_unsent: 0xb74f3008, cmd:
/>/ 0xb7411fe8)
/>/ User : 232 29125 command.c:539 command_print(): 57344 bytes written at
/>/ address 0x86000000
/>/ User : 233 29126 command.c:539 command_print(): downloaded 57344 bytes
/>/ in 3.576233s (15.659 kb/s)
/>/
/>/
/>>/ 3) Dump the loaded image and inspect it - is it well loaded in memory ?
/>/
/>/ I think fastdata may be loading it correctly, but reading it back it
/>/ is clearly bitswapped:
/>/
/>/ hexdump of original file:
/>/
/>/ 0000000 000b 1000 0000 0000 0000 0000 0000 0000
/>/ 0000010 688c 688c 0000 0000 312e 312e 0000 3000
/>/ 0000020 0000 0000 0000 0000 0000 0000 0000 0000
/>/ 0000030 7800 401b 00ff 3c08 ff00 3508 d824 0368
/>/ 0000040 0001 3c08 9500 3508 0019 1768 0000 0000
/>/ 0000050 8000 4008 8000 3c09 ffff 3529 4024 0109
/>/ 0000060 3604 3c09 4025 0109 0000 0000 8000 4088
/>/ 0000070 0040 0000 0040 0000 0040 0000 00c0 0000
/>/ 0000080 6000 4008 fffc 3c09 ffff 3529 4024 0109
/>/ 0000090 0000 2409 4025 0109 0000 0000 6000 4088
/>/ 00000a0 0040 0000 0040 0000 0040 0000 00c0 0000
/>/ 00000b0 0001 3c08 8000 3508 0007 1368 0000 0000
/>/ 00000c0 0001 3c08 8400 3508 0003 1368 0000 0000
/>/ 00000d0 0019 1000 0000 0000 8000 4008 8000 3c09
/>/ 00000e0 ffff 3529 4024 0109 3600 3c09 4025 0109
/>/ 00000f0 0000 0000 8000 4088 0040 0000 0040 0000
/>/
/>/ The file was loaded using fastdata_xfer and then read back, hexdump:
/>/
/>/ 0000000 0010 0b00 0000 0000 0000 0000 0000 0000
/>/ 0000010 8c68 8c68 0000 0000 2e31 2e31 0030 0000
/>/ 0000020 0000 0000 0000 0000 0000 0000 0000 0000
/>/ 0000030 1b40 0078 083c ff00 0835 00ff 6803 24d8
/>/ 0000040 083c 0100 0835 0095 6817 1900 0000 0000
/>/ 0000050 0840 0080 093c 0080 2935 ffff 0901 2440
/>/ 0000060 093c 0436 0901 2540 0000 0000 8840 0080
/>/ 0000070 0000 4000 0000 4000 0000 4000 0000 c000
/>/ 0000080 0840 0060 093c fcff 2935 ffff 0901 2440
/>/ 0000090 0924 0000 0901 2540 0000 0000 8840 0060
/>/ 00000a0 0000 4000 0000 4000 0000 4000 0000 c000
/>/ 00000b0 083c 0100 0835 0080 6813 0700 0000 0000
/>/ 00000c0 083c 0100 0835 0084 6813 0300 0000 0000
/>/ 00000d0 0010 1900 0000 0000 0840 0080 093c 0080
/>/ 00000e0 2935 ffff 0901 2440 093c 0036 0901 2540
/>/ 00000f0 0000 0000 8840 0080 0000 4000 0000 4000
/>/
/>/
/>/ If I load a smaller image which does not use fastdata then it reads
/>/ back exactly the same as it was written, but clearly in memory it is
/>/ bitswapped.
/>/
/>/ Andy
/>/
/>/
/>>/
/>>/ If this does not work, you can forget any debugging...
/>>/
/>>/ Best regards,
/>>/ Drasko
/>>/
/>>/ On Thu, Mar 24, 2011 at 11:43 AM, Andrew Lyon <andrew.lyon at gmail.com
<https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote:
/>>>/ On Wed, Mar 23, 2011 at 2:06 PM, Drasko DRASKOVIC
/>>>/ <drasko.draskovic at gmail.com
<https://lists.berlios.de/mailman/listinfo/openocd-development>> 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.lyon at gmail.com
<https://lists.berlios.de/mailman/listinfo/openocd-development>> 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 at lists.berlios.de
<https://lists.berlios.de/mailman/listinfo/openocd-development>
/>>>>>/ 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
