On Fri, Mar 25, 2011 at 11:40 AM, Drasko DRASKOVIC <drasko.drasko...@gmail.com> wrote: > 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 have applied them and recompiling now to test again, but looking at the source they will only fix memory read/write, not the other problems I mentioned with step and resume, perhaps they need similar fixes? > > 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 ? Its a guruplug jtag module http://www.globalscaletechnologies.com/p-28-guruplug-jtag.aspx Have you tried using libftxx instead of libftdi? > > 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
