Maybe there is some write protect pin.
On Mon, Apr 18, 2011 at 4:24 PM, Rogan Dawes <[email protected]> wrote: > On 2011/04/18 8:51 PM, Alexandre Pereira da Silva wrote: >> I couldn't see much wrong besides: >> flash bank eightMB cfi 0xff800000 0x800000 1 2 feroceon.cpu >> >> This one is working for me: >> flash bank extnor cfi 0x81000000 0x100000 1 1 $_TARGETNAME x16_as_x8 >> jedec_probe >> >> You should confirm the real bus witdh. Normally you can configure >> either as x16 or x8. And you have to make sure your reset-init does >> initialize it. >> >> You missed the x16_as_x8 parameter too. >> >> If that doesn't work, you will have to debug the source code in cfi.c >> >> Thanks. > > Hi Alexandre, > > Your working cfi definition worked for me, too, after adjusting > addresses and sizes. Thanks you! Now the flash is recognized, and all > the sectors are properly identified. > > However, I am still not able to flash a replacement firmware to the > part. It seem that the unprotect command fails, and thus the file cannot > be written to the flash. > > I placed a debug log of the following command: > > openocd -f buspirate.cfg -f dns323.cfg -d3 -l openocd.log \ > -c "flash probe 0" \ > -c "flash info 0" \ > -c "flash erase_address pad unlock 0xfffd0000 0x30000" \ > -c "flash write_image erase unlock mtdblock4 0xfffd0000" \ > -c "shutdown" > > at: > > http://dawes.za.net/rogan/openocd-20110418-211900.log.gz > > The only difference in config files is the flash definition changed to: > > flash bank eightMB cfi 0xff800000 0x800000 1 1 $_TARGETNAME x16_as_x8 > jedec_probe > > as suggested. > > Any ideas why the flash unprotect might fail? > > Thanks > > Rogan > >> >> On Mon, Apr 18, 2011 at 2:32 PM, Rogan Dawes <[email protected]> wrote: >>> On 2011/04/18 5:52 PM, Alexandre Pereira da Silva wrote: >>>> Hi, >>>> >>>> I've had some similar problems like that in the past. It was about a >>>> non-cfi x16 part connected to a x8 bus. Which flash part are you >>>> trying to program? Can you send a verbose log of what openocd is >>>> trying to do to detect your part? >>>> >>>> Thanks. >>> >>> The flash chip is a Spansion S29GL064M90TFIR4. To the best of my >>> knowledge (and according to the datasheet), it IS a CFI part. >>> >>> It is just that the detection routine required to detect it on an 8-bit >>> bus is slightly different than OpenOCD is attempting. >>> >>> I placed a debug log of the following command: >>> >>> /usr/local/bin/openocd -f buspirate.cfg -f dns323.cfg -d3 -l openocd.log >>> -c "flash probe 0" -c "shutdown" >>> >>> on my website at: >>> >>> http://dawes.za.net/rogan/openocd-20110418-182940.log >>> >>> Config files are: >>> >>> http://dawes.za.net/rogan/buspirate.cfg >>> http://dawes.za.net/rogan/dns323.cfg >>> >>> I hope that is everything required? If anything else is needed, please >>> let me know. >>> >>> Thanks >>> >>> Rogan >>> >>>> >>>> On Mon, Apr 18, 2011 at 8:47 AM, Rogan Dawes <[email protected]> wrote: >>>>> Hi folks, >>>>> >>>>> I have a D-Link DNS323, which has an 8MB Spansion flash chip in it. >>>>> >>>>> The CPU is a Marvell Orion5x (Feroceon) MV88F5182 (CPUTAPID 0x07926041, >>>>> which is not in the existing sources, FWIW). >>>>> >>>>> I can identify the CPU fine, but am unable to identify the flash part. I >>>>> suspect that part of the problem is that the flash part is a 16-bit >>>>> device on an 8-bit bus, and consequently probe addresses and read >>>>> addresses need to be doubled. >>>>> >>>>> The thread starting here: >>>>> >>>>> http://lists.denx.de/pipermail/u-boot/2010-July/073885.html >>>>> >>>>> details some of the things attempted to get it to work with U-Boot, with >>>>> a hacky solution shown here: >>>>> >>>>> http://www.mail-archive.com/[email protected]/msg49320.html >>>>> >>>>> I have seen that the OpenOCD CFI cfi driver also has code to double the >>>>> address (using cfi_info->x16_as_x8 as a flag), but I think the initial >>>>> probe does not know to set that flag, and even hard coding it to 1 >>>>> doesn't work. >>>>> >>>>> The main oddity seems to be that to enter CFI command mode, the >>>>> following commands work: >>>>> >>>>> mw.w 0xff8000aa 9800 (rather than 9898 which the U-Boot code defaulted to) >>>>> >>>>> or >>>>> >>>>> mw.b 0xff8000aa 98 (also worked fine to enter QRY mode) >>>>> >>>>> The results then looked like: >>>>> >>>>> md.b 0xff800020 20 >>>>> ff800020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY....@@.... >>>>> ff800030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 04 04 ......''66...... >>>>> >>>>> Note: I have bricked my DNS323 (hence my interest in OpenOCD! :-) ) and >>>>> cannot regain access to the U-Boot shell to repeat this at the moment. >>>>> >>>>> In OpenOCD, however, neither of those commands result in the chip >>>>> entering command mode, surprisingly. And, the existing CFI driver does >>>>> not identify the chip. >>>>> >>>>> Does anyone have any suggestions as to how I can regain access to the >>>>> flash on this device? >>>>> >>>>> Many thanks! >>>>> >>>>> Rogan >>>>> _______________________________________________ >>>>> Openocd-development mailing list >>>>> [email protected] >>>>> https://lists.berlios.de/mailman/listinfo/openocd-development >>>>> >>> >>> > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
