[U-Boot-Users] Problem with the ST Microlectronics M29W320B flashand the CFI driver.
listmember at orkun.us
Tue Dec 5 01:07:12 CET 2006
Txema Lopez wrote:
> Tolunay Orkun wrote:
> Thanks Tolunay.
>> You using M29W320DB (bottom boot) chip right?
There is a specific comment regarding this chip in cfi_flash.c around line
136 (ref: head of repository at this moment). In your board config file you
might need the following.
Also, try U-Boot start CFI detection at 16-bit port width using:
#define CFG_FLASH_CFI_WIDTH FLASH_CFI_16BIT
>> What is the flash configuration that you are using with BDI2000? Can
>> you paste that part of BDI config file?
> WM32 0x80000004 0x0000FFC0 ;CS0 start = 0xFFC000000
> WM32 0x80000008 0x0000FFFF ;CS0 stop = 0xFFFFFFFF
> WM32 0x80000300 0x00047800 ;BOOT ctrl
Umm, I am not familiar with your CPU. I meant [FLASH] section....
>> Are you using the CFI driver from top of the tree?
> No, I've done the porting for my board with the 1.1.4 version. I'll try
> to do the porting to the top of the tree.
Try it. Provided that portwidth and chipwidth are properly identified by
flash_detect_cfi(), it will probably will be mis-detected as top boot flash
part since CFI version is 1.0 for this chip and device id has bit 7 set
(0x80) as far as I remember from the datasheet.
This is because CFI 1.0 does not have proper top/bottom boot flag and AMD
style flash is brain-dead in this respect. The same guess is in Linux CFI
driver as well. Specific info->manufacturer_id and info->device_id check
should be used to identify this chip there if the device id has bit 7 set
and avoid incorrectly reversing the geometry.
Please issue flinfo command with the latest cfi_flash driver and verify that
sector addresses are correct as well as port/chip width identification...
>> What exactly was your command?
> mmh 0xffc000aa 0x9800
> mmb 0xffc000aa 0x98
> The output it's the same for both commands,
What happens if you issue:
mmh 0xffc000aa 0x9898
If both chips are in x8 mode and interleaved you should see double output
basically one byte coming from each chip. So QQRRYY should be seen...
Also, try the mw.h command in u-boot command line to duplicate the results
with BDI. You should see the same dump with md from either BDI and U-Boot.
If not, double check your CS setup within U-Boot.
>> This output is looking like for x16 but byte reversed. Is it possible
>> that hardware designer reversed the data bus? If not your CS
>> programming/logic for the flash might not be correct... Also check
>> BYTE pin of your flash parts. For x8 mode it should be pulled low.
> But, U-Boot is running properly from this flash. If the hardware was
I think it is looking that way because you are issuing the command to low
address byte only. Issue the command to both chips like I said.
> wrong could be it possible?
Try the two defines I sent. Let's see flinfo output...
> We have another board with the same schematics mounted with a spansion
> flash and we haven't got any problem. Could be a bug in the mounting
> process or is it a different behaviour of the flash accesing the CFI ?
If both chips are interfaced exactly the same and both board CS
initialization are the same then the difference could be somewhat odd
behavior of ST chip. Spansion's current products are CFI version > 1.0 so
the mis-detection of geometry could not happen.
More information about the U-Boot