Rolf, Yes - I'm running without defining a working area. Unfortunately, I seem to be getting the sort of write speeds normally reserved for paper tape and acoustic couplers. (which is why I called for help on this list!)
I was hoping that block write and/or fastdata would help me out. I can use code and hack on it a bit, but I'm nowhere near able to fix something like this... Thanks, -S At 12:02 AM 9/21/2009, Rolf Meeser wrote: >Hi Stephan, > >Thanks! > >I just saw that you are using a MIPS processor. The >cfi_spansion_write_block() function supports ARM targets only. >Currently this executes ARM opcodes on your machine, so you can be >lucky that it returned at all :-) >There is no checking the architecture yet. > >I believe your only choice at the moment is to not define a working >area (or one that has a ~300 bytes maximum). That would ensure that >the ARM code doesn't get executed because of low resources. > >Or maybe you want to fix it? :-) > >Regards, >Rolf > >Anyone: How can I detect most efficiently that a target supports ARM code? > > > > >--- Stephan Winokur <m...@swinokur.com> schrieb am Mo, 21.9.2009: > > > Von: Stephan Winokur <m...@swinokur.com> > > Betreff: Re: AW: [Openocd-development] problems with FASTDATA > bulk write and spansion flash > > An: "Rolf Meeser" <rolfm_...@yahoo.de>, > openocd-development@lists.berlios.de > > Datum: Montag, 21. September 2009, 7:47 > > Hi Rolf, > > > > The device is a Spansion S29GL512P11TFI01. > > > > flash info 0 says: > > > flash info 0 > > #0 : cfi at 0x48000000, size 0x04000000, buswidth 2, > > chipwidth 2 > > # 0: 0x00000000 (0x20000 > > 128kB) protection state unknown > > # 1: 0x00020000 (0x20000 > > 128kB) protection state unknown > > # 2: 0x00040000 (0x20000 > > 128kB) protection state unknown > > # 3: 0x00060000 (0x20000 > > 128kB) protection state unknown > > # 4: 0x00080000 (0x20000 > > 128kB) protection state unknown > > # 5: 0x000a0000 (0x20000 > > 128kB) protection state unknown > > # 6: 0x000c0000 (0x20000 > > 128kB) protection state unknown > > # 7: 0x000e0000 (0x20000 > > 128kB) protection state unknown > > # 8: 0x00100000 (0x20000 > > 128kB) protection state unknown > > [...] > > #510: 0x03fc0000 (0x20000 > > 128kB) protection state unknown > > #511: 0x03fe0000 (0x20000 > > 128kB) protection state unknown > > > > cfi information: > > > > mfr: 0x0001, id:0x227e > > qry: 'QRY', pri_id: 0x0002, pri_addr: 0x0040, alt_id: > > 0x0000, alt_addr: 0x0000 > > Vcc min: 2.7, Vcc max: 3.6, Vpp min: 0.0, Vpp max: 0.0 > > typ. word write timeout: 64, typ. buf write timeout: 64, > > typ. block erase timeout: 512, typ. chip erase timeout: > > 524288 > > max. word write timeout: 512, max. buf write timeout: 2048, > > max. block erase timeout: 4096, max. chip erase timeout: > > 2097152 > > size: 0x4000000, interface desc: 2, max buffer write size: > > 40 > > > > Spansion primary algorithm extend information: > > pri: 'PRI', version: 1.3 > > Silicon Rev.: 0x5, Address Sensitive unlock: 0x0 > > Erase Suspend: 0x2, Sector Protect: 0x1 > > VppMin: 11.5, VppMax: 12.5 > > > > > > > > > > > > At 10:40 PM 9/20/2009, Rolf Meeser wrote: > > > Hi Stephan, > > > > > > What is the exact type number of the flash device? > > > > > > Regards, > > > Rolf > > > > > > --- Stephan Winokur <m...@swinokur.com> > > schrieb am Mo, 21.9.2009: > > > > > > > Von: Stephan Winokur <m...@swinokur.com> > > > > Betreff: [Openocd-development] problems with > > FASTDATA bulk write and spansion flash > > > > An: openocd-development@lists.berlios.de > > > > Datum: Montag, 21. September 2009, 4:45 > > > > Hi all, > > > > > > > > I'm trying to make faster flash writes happen on > > a mips > > > > based > > > > platform -- because this is crazy: wrote 524288 > > byte from > > > > file > > > > /root/flashme.bin in 45807.718750s (0.011177 > > kb/s). > > > > > > > > I've downloaded the svn snapshot (2734), applied > > the > > > > "FASTDATA" bulk > > > > write optimization, and made the necessary > > changes in my > > > > target to > > > > add a working area. (mww and mdw show me > > able to > > > > modify values, read > > > > them back, etc.) > > > > > > > > (the target line is: target create $_TARGETNAME > > mips_m4k > > > > -endian > > > > $_ENDIAN -variant ejtag_srst -chain- > > > > position $_TARGETNAME -work-area-phys > > 0xb0100000 > > > > -work-area-size 0x1000) > > > > > > > > > > > > When I try to write flash, I get this error: > > > > > > > > Debug: 260 36117 target.c:1108 > > target_write_buffer(): > > > > writing buffer > > > > of 2048 byte at 0xb0100060 > > > > Debug: 261 36117 mips_m4k.c:990 > > > > mips_m4k_bulk_write_memory(): > > > > address: 0xb0100060, count: 0x00000200 > > > > Debug: 262 36117 target.c:962 > > target_alloc_working_area(): > > > > allocating > > > > new working area > > > > Info : 266 37460 mips32_pracc.c:858 > > > > mips32_pracc_fastdata_xfer(): > > > > mips32_pracc_fastdata_xfer using 0xb0100860 for > > write > > > > handler > > > > > > > > Debug: 267 37504 cfi.c:1562 > > cfi_spansion_write_block(): > > > > status: 0xb7fac190 > > > > Error: 268 37504 flash.c:100 > > flash_driver_write(): error > > > > writing to > > > > flash at address 0x48000000 at offset 0x00000000 > > (-902) > > > > > > > > When I try to use load_image, I get this error: > > > > > > > > > load_image /root/small.bin 0xb0200000 > > > > mips32_pracc_fastdata_xfer using 0xb0100000 for > > write > > > > handler > > > > > > > > User : 134 6572 mips32.c:269 mips32_arch_state(): > > target > > > > halted due > > > > to debug-request, pc: 0xbfc00000 > > > > Debug: 136 10713 command.c:68 script_debug(): > > command - > > > > load_image > > > > Debug: 137 10713 command.c:77 script_debug(): > > load_image - > > > > > > > > argv[0]=ocd_load_image > > > > Debug: 138 10713 command.c:77 script_debug(): > > load_image - > > > > > > > > argv[1]=/root/small.bin > > > > Debug: 139 10713 command.c:77 script_debug(): > > load_image - > > > > argv[2]=0xb0200000 > > > > Debug: 140 10713 configuration.c:83 find_file(): > > found > > > > /root/small.bin > > > > Debug: 141 10714 configuration.c:83 find_file(): > > found > > > > /root/small.bin > > > > Debug: 142 10714 target.c:1108 > > target_write_buffer(): > > > > writing buffer > > > > of 10470 byte at 0xb0200000 > > > > Debug: 143 10714 mips_m4k.c:990 > > > > mips_m4k_bulk_write_memory(): > > > > address: 0xb0200000, count: 0x00000a39 > > > > Debug: 144 10714 target.c:962 > > target_alloc_working_area(): > > > > allocating > > > > new working area > > > > Info : 147 12057 mips32_pracc.c:858 > > > > mips32_pracc_fastdata_xfer(): > > > > mips32_pracc_fastdata_xfer using 0xb0100000 for > > write > > > > handler > > > > > > > > Error: 148 12127 mips32_pracc.c:921 > > > > mips32_pracc_fastdata_xfer(): > > > > mini program did not return to start > > > > > > > > Debug: 149 12127 mips_m4k.c:887 > > mips_m4k_write_memory(): > > > > address: > > > > 0xb02028e4, size: 0x00000001, count: 0x00000002 > > > > Debug: 150 12129 mips32_pracc.c:105 > > wait_for_pracc_rw(): > > > > DEBUGMODULE: > > > > No memory access in progress! > > > > > > > > Debug: 151 12129 command.c:444 run_command(): > > Command > > > > failed with > > > > error code -107 > > > > User : 152 12129 command.c:646 > > openocd_jim_vfprintf(): > > > > Runtime error, > > > > file "command.c", line 473: > > > > User : 153 12129 > > command.c:646 > > > > openocd_jim_vfprintf(): > > > > > > > > Thanks! > > > > > > > > -S > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Openocd-development mailing list > > > > Openocd-development@lists.berlios.de > > > > https://lists.berlios.de/mailman/listinfo/openocd-development > > > > > > > > > > Stephan Winokur "Il silenzio di un > > bacio vale più di mille parole." > > m...@swinokur.com > > > > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
