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. Which dongle are you using ? Best regards, Drasko On Fri, Mar 25, 2011 at 11:52 AM, Andrew Lyon <andrew.l...@gmail.com> wrote: > On Thu, Mar 24, 2011 at 11:01 AM, Drasko DRASKOVIC > <drasko.drasko...@gmail.com> 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.l...@gmail.com> wrote: >>> 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
