Re: [Openocd-development] MIPS and Big Endian
On 24/03/2011 11:33, Drasko DRASKOVIC wrote: So, does anybody have an idea why we add these extra 5 clocks and how we can fine-tune this as it seems to depend on adapter_khz option also ? the commit that added the delay was 837555ab24ab32af163b5dd295dcdbc3c238ad6f. May be worth asking the author Nico Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 jtag mips performance
On 24/03/2011 11:01, Drasko DRASKOVIC wrote: 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 I am not really following the big endian issues, however i can confirm that mips32_pracc_fastdata_xfer is working for pic32 - which is little endian. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 jtag mips performance
On Fri, Mar 25, 2011 at 11:01 AM, Spencer Oliver s...@spen-soft.co.uk wrote:
I am not really following the big endian issues, however i can confirm that
mips32_pracc_fastdata_xfer is working for pic32 - which is little endian.
Hi Spen,
I am suspicious about this. Take these lines of code for example :
/* Send the load start address */
val = addr;
mips_ejtag_set_instr(ejtag_info, EJTAG_INST_FASTDATA);
mips_ejtag_fastdata_scan(ejtag_info, 1, val);
/* Send the load end address */
val = addr + (count - 1) * 4;
mips_ejtag_set_instr(ejtag_info, EJTAG_INST_FASTDATA);
mips_ejtag_fastdata_scan(ejtag_info, 1, val);
for (i = 0; i count; i++)
{
/* Send the data out using fastdata (clears the access pending
bit) */
if ((retval = mips_ejtag_fastdata_scan(ejtag_info, write_t,
buf++))
!= ERROR_OK)
return retval;
}
Obviausly, there is an inconsistency of mips_ejtag_fastdata_scan() in
the loop comparing to previous references - it is not preceded by
mips_ejtag_set_instr(). How are you sending data without telling EJTAG
what to do with it ? Maybe it remembers previous instruction in the
case of PIC32, I don't know. But from my point of view if this work is
by chance of architecture specific feature. In any case, for my
MIPS-14Kc it will not work - which does not suprise me at all.
I am waiting on the response from Andrew on the mentioned questions in
the previous mail, and if his case also confirms my suspicions I will
send the patch.
Best regards,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 jtag mips performance
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: 932d Correct Value: 0xbf8011d0 0x2D93 mdw 0xbf8011e0 1 0xbf8011e0: 3582 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 0x8600 Debug: 220 25550 mips_m4k.c:984 mips_m4k_bulk_write_memory(): address: 0x8600, count: 0x3800 Debug: 221 25551 target.c:1072 target_alloc_working_area(): MMU disabled, using physical address for working memory 0xa060 Debug: 222 25551 target.c:1134 target_alloc_working_area(): allocated new working area at address 0xa060 Debug: 228 28508 mips32_pracc.c:971 mips32_pracc_fastdata_xfer(): mips32_pracc_fastdata_xfer using 0xa060 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 0x8600 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: 000 000b 1000 010 688c 688c 312e 312e 3000 020 030 7800 401b 00ff 3c08 ff00 3508 d824 0368 040 0001 3c08 9500 3508 0019 1768 050 8000 4008 8000 3c09 3529 4024 0109 060 3604 3c09 4025 0109 8000 4088 070 0040 0040 0040 00c0 080 6000 4008 fffc 3c09 3529 4024 0109 090 2409 4025 0109 6000 4088 0a0 0040 0040 0040 00c0 0b0 0001 3c08 8000 3508 0007 1368 0c0 0001 3c08 8400 3508 0003 1368 0d0 0019 1000 8000 4008 8000 3c09 0e0 3529 4024 0109 3600 3c09 4025 0109 0f0 8000 4088 0040 0040 The file was loaded using fastdata_xfer and then read back, hexdump: 000 0010 0b00 010 8c68 8c68 2e31 2e31 0030 020 030 1b40 0078 083c ff00 0835 00ff 6803 24d8 040 083c 0100 0835 0095 6817 1900 050 0840 0080 093c 0080 2935 0901 2440 060 093c 0436 0901 2540 8840 0080 070 4000 4000 4000 c000 080 0840 0060 093c fcff 2935 0901 2440 090 0924 0901 2540 8840 0060 0a0 4000 4000 4000 c000 0b0 083c 0100 0835 0080 6813 0700 0c0 083c 0100 0835 0084 6813 0300 0d0 0010 1900 0840 0080 093c 0080 0e0 2935 0901 2440 093c 0036 0901 2540 0f0 8840 0080 4000 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
Re: [Openocd-development] ft2232 jtag mips performance
On Fri, Mar 25, 2011 at 11:55 AM, Andrew Lyon andrew.l...@gmail.com wrote: Drasko, I read somewhere that some bigendian mips systems still have little endian tap This is true. I am not MIPS expert, I am going through EJTAG manual right now to find confirmations... , perhaps that explains why on my system data loaded using fastdata is ok (it is aware of endianness), but everything else is bitswapped because my board does not have the little endian tap. I would say that next thing is happening - every call to mips_m4k_write_memory() is wrong because it do not handle endianess - it misses David Claffey's patch, as we discussed in this thread : http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15770.html However, mips32_pracc_fastdata_xfer() has a piece of code that threat the endianess, and when it suceeds it's OK. My problem is that mips32_pracc_fastdata_xfer() did not work for me and was always filing to simple mips_m4k_write_memory(). This is discussed in more details here : http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15770.html But mips32_pracc_fastdata_xfer() succeeds in your case, so does for Oliver. I'll have to investigate some more and post my observations. I see some problems in mips32_pracc_fastdata_xfer() implementation thet are not consistent to EJTAG specification by my opinion, and when I correct these it starts working for me. My problem now is that it works for all of you without changes, so maybe I am seeing something wrong. Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 jtag mips performance
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: 932d Correct Value: 0xbf8011d0 0x2D93 mdw 0xbf8011e0 1 0xbf8011e0: 3582 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 0x8600 Debug: 220 25550 mips_m4k.c:984 mips_m4k_bulk_write_memory(): address: 0x8600, count: 0x3800 Debug: 221 25551 target.c:1072 target_alloc_working_area(): MMU disabled, using physical address for working memory 0xa060 Debug: 222 25551 target.c:1134 target_alloc_working_area(): allocated new working area at address 0xa060 Debug: 228 28508 mips32_pracc.c:971 mips32_pracc_fastdata_xfer(): mips32_pracc_fastdata_xfer using 0xa060 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 0x8600 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: 000 000b 1000 010 688c 688c 312e 312e 3000 020 030 7800 401b 00ff 3c08 ff00 3508 d824 0368 040 0001 3c08 9500 3508 0019 1768 050 8000 4008 8000 3c09 3529 4024 0109 060 3604 3c09 4025 0109 8000 4088 070 0040 0040 0040 00c0 080 6000 4008 fffc 3c09 3529 4024 0109 090 2409 4025 0109 6000 4088 0a0 0040 0040 0040 00c0 0b0 0001 3c08 8000 3508 0007 1368 0c0 0001 3c08 8400 3508 0003 1368 0d0 0019 1000 8000 4008 8000 3c09 0e0 3529 4024 0109 3600 3c09 4025 0109 0f0 8000 4088 0040 0040 The file was loaded using fastdata_xfer and then read back, hexdump: 000 0010 0b00 010 8c68 8c68 2e31 2e31 0030 020 030 1b40 0078 083c ff00 0835 00ff 6803 24d8 040 083c 0100 0835 0095 6817 1900 050
Re: [Openocd-development] ft2232 jtag mips performance
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: 932d Correct Value: 0xbf8011d0 0x2D93 mdw 0xbf8011e0 1 0xbf8011e0: 3582 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 0x8600 Debug: 220 25550 mips_m4k.c:984 mips_m4k_bulk_write_memory(): address: 0x8600, count: 0x3800 Debug: 221 25551 target.c:1072 target_alloc_working_area(): MMU disabled, using physical address for working memory 0xa060 Debug: 222 25551 target.c:1134 target_alloc_working_area(): allocated new working area at address 0xa060 Debug: 228 28508 mips32_pracc.c:971 mips32_pracc_fastdata_xfer(): mips32_pracc_fastdata_xfer using 0xa060 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 0x8600 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: 000 000b 1000 010 688c 688c 312e 312e 3000 020 030 7800 401b 00ff 3c08 ff00 3508 d824 0368 040 0001 3c08 9500 3508 0019 1768 050 8000 4008 8000 3c09 3529 4024 0109 060 3604 3c09 4025 0109 8000 4088 070 0040 0040 0040 00c0 080 6000 4008 fffc 3c09 3529 4024 0109 090 2409 4025 0109 6000 4088 0a0 0040 0040 0040 00c0 0b0 0001 3c08 8000 3508 0007 1368 0c0 0001 3c08 8400 3508 0003 1368 0d0 0019 1000
Re: [Openocd-development] ft2232 jtag mips performance
On Fri, Mar 25, 2011 at 1:02 PM, Andrew Lyon andrew.l...@gmail.com wrote: 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? This might be fixed, because OpenOCD probably uses these functions to write bkpt instructions... I do not know, still did not test - I'll do it right now and report back. 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? Yes, same problem... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] compile failure due to recent cortex changes
Hi, The recent cortex commits cause compile to fail: make[5]: Entering directory `/usr/src/openocd-git/src/target' /bin/sh ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src -I../../src -DPKGDATADIR=\/usr/local/share/openocd\ -I../../jimtcl -I../../jimtcl -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT cortex_a8.lo -MD -MP -MF .deps/cortex_a8.Tpo -c -o cortex_a8.lo cortex_a8.c libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src -I../../src -DPKGDATADIR=\/usr/local/share/openocd\ -I../../jimtcl -I../../jimtcl -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT cortex_a8.lo -MD -MP -MF .deps/cortex_a8.Tpo -c cortex_a8.c -o cortex_a8.o mv -f .deps/cortex_a8.Tpo .deps/cortex_a8.Plo make[5]: *** No rule to make target `cortex_a9.c', needed by `cortex_a9.lo'. Stop. I tried reverting just dec80e1cffa162ba0e1cd8e6ee66c7784fe79b87 but it still failed and I had to go back to ec2b8d71ac1fb2e8d6c8057a5e1d0a27bd7bd110 for the compile to be successful. Andy ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] compile failure due to recent cortex changes
Try: make distclean sh bootstrap ./configure --enable-maintainer-mode -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 jtag mips performance
Hi Drasko, 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. I did not reproduce your trouble, but we already see couldn't read enough bytes from FT2232 device , when we started with the JTAGkey-2 (FT2232H), but is was coming from a too old driver, bugged with the FT2232H part. But this should not be your trouble, since you work with updated drivers. Also, the JTAGkey-2 is not your trouble since everything else is stable for you (other target board ... jtag chain detection ...), and since you do not use RTCK ... Question: -- Do you run openocd on 64bits or 32bits host machine ? ( Amontec Team is seeing some troubles with 64bits host machine running openocd this week , STM32 flash error and others errors. Regards, Laurent http://www.amontec.com Which dongle are you using ? Best regards, Drasko On Fri, Mar 25, 2011 at 11:52 AM, Andrew Lyon andrew.lyon at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / On Thu, Mar 24, 2011 at 11:01 AM, Drasko DRASKOVIC // drasko.draskovic at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development 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: 932d // Correct Value: 0xbf8011d0 0x2D93 // // mdw 0xbf8011e0 1 // 0xbf8011e0: 3582 // 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 0x8600 // Debug: 220 25550 mips_m4k.c:984 mips_m4k_bulk_write_memory(): address: // 0x8600, count: 0x3800 // Debug: 221 25551 target.c:1072 target_alloc_working_area(): MMU // disabled, using physical address for working memory 0xa060 // Debug: 222 25551 target.c:1134 target_alloc_working_area(): allocated // new working area at address 0xa060 // Debug: 228 28508 mips32_pracc.c:971 mips32_pracc_fastdata_xfer(): // mips32_pracc_fastdata_xfer using 0xa060 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 0x8600 // 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: // // 000 000b 1000 // 010 688c 688c 312e 312e
Re: [Openocd-development] compile failure due to recent cortex changes
On Fri, Mar 25, 2011 at 12:13 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Try: make distclean sh bootstrap ./configure --enable-maintainer-mode -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer Thanks, that fixed it, and will remember to do that in future. Andy ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 jtag mips performance
On 25/03/2011 10:37, Drasko DRASKOVIC wrote: Obviausly, there is an inconsistency of mips_ejtag_fastdata_scan() in the loop comparing to previous references - it is not preceded by mips_ejtag_set_instr(). This should not matter. The second call can be removed as the fastdata instruction is already selected in the tap. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 jtag mips performance
On Fri, Mar 25, 2011 at 12:07 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Fri, Mar 25, 2011 at 1:02 PM, Andrew Lyon andrew.l...@gmail.com wrote: 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? This might be fixed, because OpenOCD probably uses these functions to write bkpt instructions... I do not know, still did not test - I'll do it right now and report back. step does not appear to work properly, certainly if I step into a memory address then the address shown when the target is halted again is not where I asked it to step into, or even anywhere that the code I loaded could have made it jump (if some code was run before it was halted again) however manually setting the pc reg and then single stepping seems to work, I am currently stepping thru the uboot code and so far I can follow PC through the source dump and it makes perfect sense. so step and resume fail when a address is passed. I've got quite a way into the uboot process so don't want to stop yet and start over as its quite a slow process, but once i've done this run I will test breakpoints again, last time I tried they didn't work so I seem to be stuck with single stepping, still its better than nothing and great fun to trace the C code and asm as it runs :). Andy 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? Yes, same problem... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 jtag mips performance
On Fri, Mar 25, 2011 at 4:29 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 25/03/2011 10:37, Drasko DRASKOVIC wrote: Obviausly, there is an inconsistency of mips_ejtag_fastdata_scan() in the loop comparing to previous references - it is not preceded by mips_ejtag_set_instr(). This should not matter. The second call can be removed as the fastdata instruction is already selected in the tap. Yes, I thought that also. But it seems to mather, because not putting mips_ejtag_set_instr(ejtag_info, EJTAG_INST_FASTDATA); keeps failing load with error : mini program did not return to start And after that point OPenOCD is unusable. With mips_ejtag_set_instr(ejtag_info, EJTAG_INST_FASTDATA) within the loop it works correctly. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cortex a8/a9 debug base
On Tuesday 22 March 2011 12:16:47 Øyvind Harboe wrote: On Tue, Mar 22, 2011 at 12:14 PM, Michael Schwingen rincew...@discworld.dascon.de wrote: Øyvind Harboe wrote: I'm wondering if it would be better to ditch the automatic fixup code and use parameters to target in config script. Default would be to use the automatic detection per ARM's specification. Since auto-detecting the broken devices seems to be problematic, I think that would be a good approach, because it has zero chance of breaking non-affected devices. Sold then... Patch anyone? Wasn't this what was proposed in the first place? :-) Autodetect of a few broken devices would have been sweet, but I suppose we couldn't get away with it this time... I wanted to have an option for debug base in config file at the begining, but was pushed to make the auto-detect code ;-) Sorry I didn't have further look at the code, work totaled me. Cheers ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] cortex a9: merge cortex a9 and a8 code
On Tuesday 22 March 2011 01:08:03 Aaron Carroll wrote: On 22 March 2011 01:53, luca ellero lro...@gmail.com wrote: Unfortunately at the moment I have no cortex A8 boards to test it. Anyway I wonder where 0x8000 come from, since I can't find any docs in This came from poking the omap4430. The ROM (on the two rev's I tested, anyway) is bogus, so I don't think there's a sensible way to determine the addresses are run-time. OMAP4430 has broken debug base address too ? Oh jeez :) ___ 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
Re: [Openocd-development] cortex a8/a9 debug base
I wanted to have an option for debug base in config file at the begining, but was pushed to make the auto-detect code ;-) We want autodetect as the default with manual override It was important that we *tried* to avoid the option, but we no longer think we can. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [Patch] increase buffer size for svf files
Xilinx ISE 13.1 produces svf files for Spartan XC3S50AN that are too large for the buffer to hold - causing it to fail to program. Attached is a patch that simply increases the buffer size - I tried a variety of sized buffers - they had no effect on the speed of programming. -Ali buffer.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
