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
