[U-Boot] U-boot running on DDR fails to detect the CFI compliant flash

prakash bedge prakash.bedge at gmail.com
Tue Jan 19 17:22:33 CET 2010


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


More information about the U-Boot mailing list