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.vanbaren@ge.comwrote:
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