Hi all, embedding David's solutions for mips_m4k_write_memory() and mips_m4k_read_memory() from commit b271efe12132e93cb17adb037323f6cf251305b2 seems to be solving the problem for the small files.
However, trying to load a bigger image function mips_m4k_bulk_write_memory() is called an fails in mips32_pracc_fastdata_xfer(). So, making mips_m4k_bulk_write_memory() to fall straight away to simple mips_m4k_write_memory(), like in mentioned David's commit b271efe12132e93cb17adb037323f6cf251305b2 seems to be showing better results, but I still have following error for bigger writes : couldn't read enough bytes from FT2232 device (0 < 5) couldn't read from FT2232 register read failed Do you have any idea why this is happening and can this be related to Amontec JTAG Key 2 probe I have been using ? Best regards, Drasko On Wed, Mar 16, 2011 at 4:37 PM, Drasko DRASKOVIC <[email protected]> wrote: > Even further investigation of the problem lead to these posts : > http://www.mail-archive.com/[email protected]/msg05586.html > > Can anybody tell me if the patch David proposed is well applied ? > Although there are some traces of Davids changes in the mips_ejtag.c > file, I can not see any endianess handling in mips_4k.c file, except > in mips_m4k_bulk_write_memory() function. > However mips_m4k_write_memory() and mips_m4k_read_memory() do not seem > to care about endianess and that can be the source of this problem. No > traces of David's changes here. > > Best regards, > Drasko > > On Wed, Mar 16, 2011 at 3:19 PM, Drasko DRASKOVIC > <[email protected]> wrote: >> Hi all, >> this seems to be OpenOCD endianess probelem for MIPS big endian targets. >> >> This is what I concluded with further instigation. I started target in >> little endian mode and let it configure SDRAM. In this case SDRAM is >> well configured, all values well written and load to SDRAM works >> correctly. >> >> Passing -endian big when creating target, write to the SRDAM >> controller register is wrong, and thus SDRAM is never well configured. >> >> Why is this happening and what seems to be wrong ? >> >> BR, >> Drasko >> >> On Wed, Mar 16, 2011 at 11:42 AM, Drasko DRASKOVIC >> <[email protected]> wrote: >>> Hi all, >>> I just tried to load a small test ELF like this : >>> >>> 80008000 <_ftext>: >>> 80008000: 3c088001 lui t0,0x8001 >>> 80008004: 8d089014 lw t0,-28652(t0) >>> 80008008: 24090005 li t1,5 >>> 8000800c: 3c018001 lui at,0x8001 >>> 80008010: ac299014 sw t1,-28652(at) >>> >>> to my Mips-M14Kc core, using mips_m4k as a target (they should be >>> pretty much the same). What I am seeing in the memory after write is >>> this : >>> >>>> mdw 0x80008000 0x20 >>> 0x80008000: 00000000 3c083c08 8d088d08 24092409 3c013c01 c833c833 >>> a430a430 98aa98aa >>> 0x80008020: d5b5d5b5 c822c822 719f719f d988d988 50305030 c549c549 >>> dc24dc24 0c280c28 >>> >>> So, something that resembles the code, but every half-word is repeated >>> two times, and later just trash. >>> However, I am sure that my SDRAM configuration is correct because it >>> has has been proven by Lauterbach porbe, and I just modified cmm >>> script. >>> >>> Similarly, here is example of the erroneous behavior : >>> >>>> mww 0x80000000 0x12345678 >>>> mdw 0x80000000 >>> 0x80000000: 00000000 >>>> mdw 0x80000000 0x3 >>> 0x80000000: 00000000 3c083c08 8d088d08 >>>> mww 0x80000004 0x12345678 >>>> mdw 0x80000000 0x3 >>> 0x80000000: 00000000 12341234 8d088d08 >>>> >>> >>> >>> What can be a source to this problem, and where can I start looking >>> and putting some traces to see what is wrong ? >>> >>> I am using Amontec JTAG Key2, core is Mips-M14Kc, Big Endian. OpenOCD >>> version is the latest git dev branch. >>> >>> Best regards, >>> Drasko >>> >> > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
