Hi Baren and Stefan What I find is *VERY* helpful when trying to understand flash control issues is to *manually* do the QRY write sequence (see your flash data sheet) by using memory write/read commands from the u-boot command prompt I tested the same using "mw" and "md" commands from uboot prompt for read CFI query command. But test failed.
Log details: mw 0xfc000000 0xf0 mw 0xfc000055 0x98 md 0xfc000010 fc000010: ffffffff ffffffff ffffffff ffffffff ................ fc000020: ffffffff ffffffff ffffffff ffffffff ................ fc000030: ffffffff ffffffff ffffffff ffffffff ................ fc000040: ffffffff ffffffff ffffffff ffffffff ................ fc000050: ffffffff ff000000 98ffffff ffffffff ..... ........ fc000060: ffffffff ffffffff ffffffff ffffffff ................ fc000070: ffffffff ffffffff ffffffff ffffffff ................ fc000080: ffffffff ffffffff ffffffff ffffffff ................ fc000090: ffffffff ffffffff ffffffff ffffffff ................ fc0000a0: ffffffff ffffffff ffffffff ffffffff ................ fc0000b0: ffffffff ffffffff ffffffff ffffffff ................ fc0000c0: ffffffff ffffffff ffffffff ffffffff ................ fc0000d0: ffffffff ffffffff ffffffff ffffffff ................ fc0000e0: ffffffff ffffffff ffffffff ffffffff ................ fc0000f0: ffffffff ffffffff ffffffff ffffffff ................ fc000100: ffffffff ffffffff ffffffff ffffffff ................ mw 0xfc000000 0xf0 mw 0xfc0000AA 0x98 ... This is the actual mapping. md 0xfc000020 fc000020: ffffffff ffffffff ffffffff ffffffff ................ fc000030: ffffffff ffffffff ffffffff ffffffff ................ fc000040: ffffffff ffffffff ffffffff ffffffff ................ fc000050: ffffffff ff000000 98ffffff ffffffff ..... ........ fc000060: ffffffff ffffffff ffffffff ffffffff ................ fc000070: ffffffff ffffffff ffffffff ffffffff ................ fc000080: ffffffff ffffffff ffffffff ffffffff ................ fc000090: ffffffff ffffffff ffffffff ffffffff ................ fc0000a0: ffffffff ffffffff ffff0000 0098ffff .......... ... fc0000b0: ffffffff ffffffff ffffffff ffffffff ................ fc0000c0: ffffffff ffffffff ffffffff ffffffff ................ fc0000d0: ffffffff ffffffff ffffffff ffffffff ................ fc0000e0: ffffffff ffffffff ffffffff ffffffff ................ fc0000f0: ffffffff ffffffff ffffffff ffffffff ................ fc000100: ffffffff ffffffff ffffffff ffffffff ................ fc000110: ffffffff ffffffff ffffffff ffffffff ................ I believe that I am executing correct commands. If wrong please guide me. M29W128Gh details: chip is 16 bit (is this chipwidth?) bus is 8 bit (is this portwidth?) Algorithm -AMD Banks- 1 sectors - 128 Which u-boot version you used where you do not need to change the uboot code for ST make M29W128GH? What other configuration or code I need to check in order to identify the root cause? TIA. Thanks & Regards, Prakash Bedge On Tue, Jan 19, 2010 at 7:28 PM, Jerry Van Baren <gerald.vanba...@ge.com>wrote: > Stefan Roese wrote: > >> On Tuesday 19 January 2010 07:24:10 prakash bedge wrote: >> >>> I have tried the code in the URL link you have provided. But still I am >>> facing the same problem. I am getting the error in "flash_detect_cfi" as >>> flash not found. It fails at initial stage at read CFI query command. >>> The code you have provided is for M29W128GL.(Numonix). Will this work for >>> M29W128GH (STMIcrotronics)? >>> >> >> Frankly, I don't know. You need to check the datasheets, to see if there >> are some differences. >> >> I believe Uboot support M29W128GH flash. I am using this flash chip in 16 >>> x >>> 8 bit mode. >>> The URL I provided is available under the thread: >>> "[U-Boot] Query: Does Uboot support CFI flash driver forM29W128GH". >>> Can there be an endianness issue, as I am running uboot from SDRAM and in >>> Big endian mode? >>> >> >> No, I don't think that this is an endian issue. All PPC4xx platforms are >> doing it the same way. This must be a different problem. >> >> Did you check that the NOR chip is really selected (chip select signal etc >> on the FLASH chip via oscilloscope)? Are the addresses correct for the query >> (etc) commands? >> >> Cheers, >> Stefan >> > > IIRC, Prakash added debug print statements that showed the "Q" of the "QRY" > being read, but did not show anything more. As a result, it was impossible > to tell why the CFI detect was not working. > > What I find is *VERY* helpful when trying to understand flash control > issues is to *manually* do the QRY write sequence (see your flash data > sheet) by using memory write/read commands from the u-boot command prompt. > This way I can quickly try different byte widths, lanes, etc. for the > writes and see the full QRY response from the memory. Usually the problem > is a simple misunderstanding of how the chip is configured or the hardware > is wired (beware of hardware designers doing "endian fixes"). > > Good luck, > gvb > >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
