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) 2) Is mips32_pracc_fastdata_xfer() exiting with error 3) Dump the loaded image and inspect it - is it well loaded in memory ? 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
