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. 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
