[U-Boot-Users] Problem with the ST Microlectronics M29W320B flash and the CFI driver.

[U-Boot-Users] Problem with the ST Microlectronics M29W320B flash and the CFI driver.

[Txema Lopez]

Hi all,

We have a MPC5200B based custom board with a ST Microelectronics 
M29W320B (x8/x16 flash in x8 mode) as boot flash. We are able to program 
the flash using a BDI2000 and start up U-Boot. But U-Boot is unable to 
detect the boot flash using the CFI driver. With the same hardware (but 
other board) and a flash from other vendor (Spansion S29GL32A) the CFI 
driver works properly. Has anyone tested the CFI driver for the M29W320B 
flash?

This is the BDI2000 output when we write a CFI Query command

ffc00000 : 2000 5722 FFFF FFFF FFFF FFFF FFFF FFFF   .W"............
ffc00010 : FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF  ................
ffc00020 : 5100 5200 5900 0200 0000 4000 0000 0000  Q.R.Y..... at .....
ffc00030 : 0000 0000 0000 2700 3600 b500 c500 0400  ......'.6.......
ffc00040 : 0000 0a00 0000 0400 0000 0300 0000 1600  ................
ffc00050 : 0200 0000 0000 0000 0200 0700 0000 2000  .............. .
ffc00060 : 0000 3e00 0000 0000 0100 0000 0000 8000  ..>.............
ffc00070 : 0000 3e00 0000 0000 0100 FFFF FFFF FFFF  ..>.............
ffc00080 : 5000 5200 4900 3100 3000 0000 0200 0100  P.R.I.1.0.......
ffc00090 : 0100 0400 0000 0000 0000 b500 c500 0200  ................
ffc000a0 : FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF  ................
ffc000b0 : FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF  ................
ffc000c0 : FFFF 6012 4e3b f07d 9b54 3500 2002 2003  ..`.N;.}.T5. . .
ffc000d0 : 1200 2700 3a00 0100 0000 0000 0000 0000  ..'.:...........
ffc000e0 : 0000 0f00 0700 0200 0000 0100 0100 0000  ................
ffc000f0 : 0000 0000 0000 0100 0000 0000 0000 0000  ................

AFAIK the CFI driver is waiting an output like this for a x8/x16 device 
in x8 mode:
ffc00020 : 5151 5252 5959   QQRRYY
Am I wrong?


Best regards,


-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061129/1bc72c3b/attachment.vcf 

[U-Boot-Users] Problem with the ST Microlectronics M29W320B flash and the CFI driver.

[Tolunay Orkun]

Txema Lopez wrote:
> Hi all,
> 
> We have a MPC5200B based custom board with a ST Microelectronics 
> M29W320B (x8/x16 flash in x8 mode) as boot flash. We are able to program 

You using M29W320DB (bottom boot) chip right?

http://www.st.com/stonline/products/literature/ds/7876/m29w320db.pdf

> the flash using a BDI2000 and start up U-Boot. But U-Boot is unable to 
> detect the boot flash using the CFI driver. With the same hardware (but

What is the flash configuration that you are using with BDI2000? Can you 
paste that part of BDI config file?

> other board) and a flash from other vendor (Spansion S29GL32A) the CFI 
> driver works properly. Has anyone tested the CFI driver for the M29W320B 
> flash?

Are you using the CFI driver from top of the tree? If not can you please 
use the one from top of tree? Also it would be great if you provided 
"flinfo" command output as well.

> This is the BDI2000 output when we write a CFI Query command

What exactly was your command?

> ffc00000 : 2000 5722 FFFF FFFF FFFF FFFF FFFF FFFF   .W"............
> ffc00010 : FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF  ................
> ffc00020 : 5100 5200 5900 0200 0000 4000 0000 0000  Q.R.Y..... at .....
> ffc00030 : 0000 0000 0000 2700 3600 b500 c500 0400  ......'.6.......
> ffc00040 : 0000 0a00 0000 0400 0000 0300 0000 1600  ................
> ffc00050 : 0200 0000 0000 0000 0200 0700 0000 2000  .............. .
> ffc00060 : 0000 3e00 0000 0000 0100 0000 0000 8000  ..>.............
> ffc00070 : 0000 3e00 0000 0000 0100 FFFF FFFF FFFF  ..>.............
> ffc00080 : 5000 5200 4900 3100 3000 0000 0200 0100  P.R.I.1.0.......
> ffc00090 : 0100 0400 0000 0000 0000 b500 c500 0200  ................
> ffc000a0 : FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF  ................
> ffc000b0 : FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF  ................
> ffc000c0 : FFFF 6012 4e3b f07d 9b54 3500 2002 2003  ..`.N;.}.T5. . .
> ffc000d0 : 1200 2700 3a00 0100 0000 0000 0000 0000  ..'.:...........
> ffc000e0 : 0000 0f00 0700 0200 0000 0100 0100 0000  ................
> ffc000f0 : 0000 0000 0000 0100 0000 0000 0000 0000  ................

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.

> AFAIK the CFI driver is waiting an output like this for a x8/x16 device 
> in x8 mode:
> ffc00020 : 5151 5252 5959   QQRRYY
> Am I wrong?
> 

You would normally see QQRRYY pattern if there are two x8 devices side 
by side in a 16 bit bus interface.

Tolunay

[U-Boot-Users] Problem with the ST Microlectronics M29W320B flashand the CFI driver.

[Txema Lopez]

Tolunay Orkun wrote:
    Thanks Tolunay.

> You using M29W320DB (bottom boot) chip right?

Yes

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

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

> If not can you please use the one from top of tree? Also it would be 
> great if you provided "flinfo" command output as well.
>
>
> What exactly was your command?

mmh 0xffc000aa 0x9800

or

mmb 0xffc000aa 0x98

The output it's the same for both commands,

>
>
> 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 
wrong could be it possible?
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 ?



Best regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061201/f68951b4/attachment.vcf 

[U-Boot-Users] Problem with the ST Microlectronics M29W320B flashand the CFI driver.

[Tolunay Orkun]

Txema Lopez wrote:
> Tolunay Orkun wrote:
>    Thanks Tolunay.
> 
>> You using M29W320DB (bottom boot) chip right?
> 
> Yes

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.

#define CFG_FLASH_CFI_AMD_RESET

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

Best regards,
Tolunay