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

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

[prakash bedge]

Hi Stefan,

In October 09 month, I had asked whether U-boot supports M29W128GH, a CFI
compilant chip and I got a yes reply. Please refer below URL for reference.

http://www.mail-archive.com/u-boot at lists.denx.de/msg24531.html.

So I have used Uboot for my PPC440 based board.

When I flashed U-boot on flash and then run the Uboot in DDR then U-boot
running on DDR fails to detect CFI chip M29W128GH (16M x 8 mode).

flash_detect_cfi function gives error that flash not found. I have added
debug statements for temporary debug purpose.
 Please see the below error I am getting.

The CFI query address looks different in below code and not as per ST make
M29W128GH specs. PCIMW.

static int __flash_detect_cfi (flash_info_t * info, struct cfi_qry *qry)
{
        int cfi_offset;
        debug ("1__flash detect cfi\n");
        /* We do not yet know what kind of commandset to use, so we issue
           the reset command in both Intel and AMD variants, in the hope
           that AMD flash roms ignore the Intel command. */
        flash_write_cmd (info, 0, 0, AMD_CMD_RESET);
        flash_write_cmd (info, 0, 0, FLASH_CMD_RESET);
        debug ("2__flash detect cfi\n");
        for (cfi_offset=0;
             cfi_offset < sizeof(flash_offset_cfi) / sizeof(uint);
             cfi_offset++) {
                flash_write_cmd (info, 0, flash_offset_cfi[cfi_offset],
                                 FLASH_CMD_CFI);

        debug ("3__flash detect cfi\n");
        if (flash_isequal (info, 0, FLASH_OFFSET_CFI_RESP, 'Q')
                    && flash_isequal (info, 0, FLASH_OFFSET_CFI_RESP + 1,
'R')
                    && flash_isequal (info, 0, FLASH_OFFSET_CFI_RESP + 2,
'Y')) {
                        flash_read_cfi(info, qry, FLASH_OFFSET_CFI_RESP,
                                        sizeof(struct cfi_qry));

 /* UART Output */

U-Boot 2009.08 (Jan 15 2010 - 16:44:40)
DRAM:  Meminfo.ptrCDBs: 0xc00174e0
512 MB (ECC is ON, 400 MHz, CL 7)
Top of RAM usable for U-Boot at: 20000000
Reserving 174k for U-Boot at: 1ffd4000
Reserving 1040k for malloc() at: 1fed0000
Reserving 128 Bytes for Board Info at: 1fecff80
Reserving 64 Bytes for Global Data at: 1fecff40
Stack Pointer at: 1fecff28
New Stack Pointer is: 1fecff28
after watchdog reset
after watchdog reset 2
after memcpy
befor relocate addr_sp = 1fecff28, id = 1fecff40, addr = 1ffd4000
Now running in RAM - U-Boot at: 1ffd4000
FLASH: flash detect cfi
1__flash detect cfi
fwc addr ff000000 cmd f0 f0 8bit x 8 bit
Entering into First Write
First Write is done
fwc addr ff000000 cmd ff ff 8bit x 8 bit
Entering into First Write
First Write is done
2__flash detect cfi
fwc addr ff000055 cmd 98 98 8bit x 8 bit
Entering into First Write
First Write is done
3__flash detect cfi
is= cmd 51(Q) addr ff000010 is= ff 51
fwc addr ff000555 cmd 98 98 8bit x 8 bit
Entering into First Write
First Write is done
3__flash detect cfi
is= cmd 51(Q) addr ff000010 is= ff 51
1__flash detect cfi
fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit
fwc addr ff000000 cmd ff ffff 16bit x 8 bit
2__flash detect cfi
fwc addr ff0000aa cmd 98 9898 16bit x 8 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000020 is= ffff 5151
fwc addr ff000aaa cmd 98 9898 16bit x 8 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000020 is= ffff 5151
1__flash detect cfi
fwc addr ff000000 cmd f0 00f0 16bit x 16 bit
fwc addr ff000000 cmd ff 00ff 16bit x 16 bit
2__flash detect cfi
fwc addr ff0000aa cmd 98 0098 16bit x 16 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000020 is= ffff 0051
fwc addr ff000aaa cmd 98 0098 16bit x 16 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000020 is= ffff 0051
1__flash detect cfi
fwc addr ff000000 cmd f0 f0f0f0f0 32bit x 8 bit
fwc addr ff000000 cmd ff ffffffff 32bit x 8 bit
2__flash detect cfi
fwc addr ff000154 cmd 98 98989898 32bit x 8 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000040 is= ffffffff 51515151
fwc addr ff001554 cmd 98 98989898 32bit x 8 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000040 is= ffffffff 51515151

1__flash detect cfi
fwc addr ff000000 cmd f0 00f000f0 32bit x 16 bit
fwc addr ff000000 cmd ff 00ff00ff 32bit x 16 bit
2__flash detect cfi
fwc addr ff000154 cmd 98 00980098 32bit x 16 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000040 is= ffffffff 00510051
fwc addr ff001554 cmd 98 00980098 32bit x 16 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000040 is= ffffffff 00510051
1__flash detect cfi
fwc addr ff000000 cmd f0 000000f0 32bit x 32 bit
fwc addr ff000000 cmd ff 000000ff 32bit x 32 bit
2__flash detect cfi
fwc addr ff000154 cmd 98 00000098 32bit x 32 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000040 is= ffffffff 00000051
fwc addr ff001554 cmd 98 00000098 32bit x 32 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000040 is= ffffffff 00000051

1__flash detect cfi
fwrite addr ff000000 cmd f0 f0f0f0f0f0f0f0f0 64 bit x 8 bit
fwrite addr ff000000 cmd ff ffffffffffffffff 64 bit x 8 bit
2__flash detect cfi
fwrite addr ff0002a8 cmd 98 9898989898989898 64 bit x 8 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000080 is= ffffffffffffffff 5151515151515151
fwrite addr ff002aa8 cmd 98 9898989898989898 64 bit x 8 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000080 is= ffffffffffffffff 5151515151515151

1__flash detect cfi
fwrite addr ff000000 cmd f0 00f000f000f000f0 64 bit x 16 bit
fwrite addr ff000000 cmd ff 00ff00ff00ff00ff 64 bit x 16 bit
2__flash detect cfi
fwrite addr ff0002a8 cmd 98 0098009800980098 64 bit x 16 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000080 is= ffffffffffffffff 0051005100510051
fwrite addr ff002aa8 cmd 98 0098009800980098 64 bit x 16 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000080 is= ffffffffffffffff 0051005100510051

1__flash detect cfi
fwrite addr ff000000 cmd f0 000000f0000000f0 64 bit x 32 bit
fwrite addr ff000000 cmd ff 000000ff000000ff 64 bit x 32 bit
2__flash detect cfi
fwrite addr ff0002a8 cmd 98 0000009800000098 64 bit x 32 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000080 is= ffffffffffffffff 0000005100000051
fwrite addr ff002aa8 cmd 98 0000009800000098 64 bit x 32 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000080 is= ffffffffffffffff 0000005100000051

1__flash detect cfi
fwrite addr ff000000 cmd f0 00000000000000f0 64 bit x 64 bit
fwrite addr ff000000 cmd ff 00000000000000ff 64 bit x 64 bit
2__flash detect cfi
fwrite addr ff0002a8 cmd 98 0000000000000098 64 bit x 64 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000080 is= ffffffffffffffff 0000000000000051
fwrite addr ff002aa8 cmd 98 0000000000000098 64 bit x 64 bit
3__flash detect cfi
is= cmd 51(Q) addr ff000080 is= ffffffffffffffff 0000000000000051
not found
## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
flash_protect ON: from 0xFFFC0000 to 0xFFFE8AFF
flash_protect ON: from 0xFFFA0000 to 0xFFFBFFFF
*** failed ***
### ERROR ### Please RESET the board ###


What should be the cause. It would be really helpful if someone who have
face this kind of issues can give some inputs.

TIA.

Regards,
Prakash

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

[Stefan Roese]

Hi Prakash,

On Friday 15 January 2010 14:23:35 prakash bedge wrote:
> In October 09 month, I had asked whether U-boot supports M29W128GH, a CFI
> compilant chip and I got a yes reply. Please refer below URL for reference.
> 
> http://www.mail-archive.com/u-boot at lists.denx.de/msg24531.html.

Link not found. Please correct.
 
> So I have used Uboot for my PPC440 based board.
> 
> When I flashed U-boot on flash and then run the Uboot in DDR then U-boot
> running on DDR fails to detect CFI chip M29W128GH (16M x 8 mode).
> 
> flash_detect_cfi function gives error that flash not found. I have added
> debug statements for temporary debug purpose.
>  Please see the below error I am getting.
> 
> The CFI query address looks different in below code and not as per ST make
> M29W128GH specs. PCIMW.

What's the difference then? Please give an example.

I suggest you take a look at this prelimiary patch:

http://lists.denx.de/pipermail/u-boot/2009-December/065562.html

Please let me know if this helps or not.
 
Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

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

[prakash bedge]

Hi Stefan,

Thanks for information.

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

Thanks & Regards,
Prakash Bedge

Log: I have chnaged the "&&" to "||" in if(flash_isequal .... ) condition to
check QRY response.

U-Boot 2009.08 (Jan 18 2010 - 20:10:01)
FLASH: flash detect cfi
fwc addr fc000000 cmd ff ff 8bit x 8 bit
Entering into First Write
First Write is done
fwc addr fc000000 cmd f0 f0 8bit x 8 bit
Entering into First Write
First Write is done
fwc addr fc000055 cmd 98 98 8bit x 8 bit
Entering into First Write
First Write is done
is= cmd 51(Q) addr fc000010 is= ff 51
is= cmd 52(R) addr fc000011 is= ff 52
is= cmd 59(Y) addr fc000012 is= ff 59
fwc addr fc000555 cmd 98 98 8bit x 8 bit
Entering into First Write
First Write is done
is= cmd 51(Q) addr fc000010 is= ff 51
is= cmd 52(R) addr fc000011 is= ff 52
is= cmd 59(Y) addr fc000012 is= ff 59
fwc addr fc000000 cmd ff ff00 16bit x 8 bit
fwc addr fc000000 cmd f0 f000 16bit x 8 bit
fwc addr fc0000aa cmd 98 9800 16bit x 8 bit
is= cmd 51(Q) addr fc000020 is= ffff 5100
is= cmd 52(R) addr fc000022 is= ffff 5200
is= cmd 59(Y) addr fc000024 is= ffff 5900
fwc addr fc000aaa cmd 98 9800 16bit x 8 bit
is= cmd 51(Q) addr fc000020 is= ffff 5100
is= cmd 52(R) addr fc000022 is= ffff 5200
is= cmd 59(Y) addr fc000024 is= ffff 5900
fwc addr fc000000 cmd ff 0000 16bit x 16 bit
fwc addr fc000000 cmd f0 0000 16bit x 16 bit
fwc addr fc0000aa cmd 98 0000 16bit x 16 bit
is= cmd 51(Q) addr fc000020 is= ffff 0000
is= cmd 52(R) addr fc000022 is= ffff 0000
is= cmd 59(Y) addr fc000024 is= ffff 0000
fwc addr fc000aaa cmd 98 0000 16bit x 16 bit
is= cmd 51(Q) addr fc000020 is= ffff 0000
is= cmd 52(R) addr fc000022 is= ffff 0000
is= cmd 59(Y) addr fc000024 is= ffff 0000
fwc addr fc000000 cmd ff ff00ff00 32bit x 8 bit
fwc addr fc000000 cmd f0 f000f000 32bit x 8 bit
fwc addr fc000154 cmd 98 98009800 32bit x 8 bit
is= cmd 51(Q) addr fc000040 is= ffffffff 51005100
is= cmd 52(R) addr fc000044 is= ffffffff 52005200
is= cmd 59(Y) addr fc000048 is= ffffffff 59005900
fwc addr fc001554 cmd 98 98009800 32bit x 8 bit
is= cmd 51(Q) addr fc000040 is= ffffffff 51005100
is= cmd 52(R) addr fc000044 is= ffffffff 52005200
is= cmd 59(Y) addr fc000048 is= ffffffff 59005900
fwc addr fc000000 cmd ff 00000000 32bit x 16 bit
fwc addr fc000000 cmd f0 00000000 32bit x 16 bit
fwc addr fc000154 cmd 98 00000000 32bit x 16 bit
is= cmd 51(Q) addr fc000040 is= ffffffff 00000000
is= cmd 52(R) addr fc000044 is= ffffffff 00000000
is= cmd 59(Y) addr fc000048 is= ffffffff 00000000
fwc addr fc001554 cmd 98 00000000 32bit x 16 bit
is= cmd 51(Q) addr fc000040 is= ffffffff 00000000
is= cmd 52(R) addr fc000044 is= ffffffff 00000000
is= cmd 59(Y) addr fc000048 is= ffffffff 00000000
fwc addr fc000000 cmd ff 00000000 32bit x 32 bit
fwc addr fc000000 cmd f0 00000000 32bit x 32 bit
fwc addr fc000154 cmd 98 00000000 32bit x 32 bit
is= cmd 51(Q) addr fc000040 is= ffffffff 00000000
is= cmd 52(R) addr fc000044 is= ffffffff 00000000
is= cmd 59(Y) addr fc000048 is= ffffffff 00000000
fwc addr fc001554 cmd 98 00000000 32bit x 32 bit
is= cmd 51(Q) addr fc000040 is= ffffffff 00000000
is= cmd 52(R) addr fc000044 is= ffffffff 00000000
is= cmd 59(Y) addr fc000048 is= ffffffff 00000000
fwrite addr fc000000 cmd ff ff00ff00ff00ff00 64 bit x 8 bit
fwrite addr fc000000 cmd f0 f000f000f000f000 64 bit x 8 bit
fwrite addr fc0002a8 cmd 98 9800980098009800 64 bit x 8 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 5100510051005100
is= cmd 52(R) addr fc000088 is= ffffffffffffffff 5200520052005200
is= cmd 59(Y) addr fc000090 is= ffffffffffffffff 5900590059005900
fwrite addr fc002aa8 cmd 98 9800980098009800 64 bit x 8 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 5100510051005100
is= cmd 52(R) addr fc000088 is= ffffffffffffffff 5200520052005200
is= cmd 59(Y) addr fc000090 is= ffffffffffffffff 5900590059005900
fwrite addr fc000000 cmd ff 0000000000000000 64 bit x 16 bit
fwrite addr fc000000 cmd f0 0000000000000000 64 bit x 16 bit
fwrite addr fc0002a8 cmd 98 0000000000000000 64 bit x 16 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000000000000000
is= cmd 52(R) addr fc000088 is= ffffffffffffffff 0000000000000000
is= cmd 59(Y) addr fc000090 is= ffffffffffffffff 0000000000000000
fwrite addr fc002aa8 cmd 98 0000000000000000 64 bit x 16 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000000000000000
is= cmd 52(R) addr fc000088 is= ffffffffffffffff 0000000000000000
is= cmd 59(Y) addr fc000090 is= ffffffffffffffff 0000000000000000
fwrite addr fc000000 cmd ff 0000000000000000 64 bit x 32 bit
fwrite addr fc000000 cmd f0 0000000000000000 64 bit x 32 bit
fwrite addr fc0002a8 cmd 98 0000000000000000 64 bit x 32 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000000000000000
is= cmd 52(R) addr fc000088 is= ffffffffffffffff 0000000000000000
is= cmd 59(Y) addr fc000090 is= ffffffffffffffff 0000000000000000
fwrite addr fc002aa8 cmd 98 0000000000000000 64 bit x 32 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000000000000000
is= cmd 52(R) addr fc000088 is= ffffffffffffffff 0000000000000000
is= cmd 59(Y) addr fc000090 is= ffffffffffffffff 0000000000000000
fwrite addr fc000000 cmd ff 0000000000000000 64 bit x 64 bit
fwrite addr fc000000 cmd f0 0000000000000000 64 bit x 64 bit
fwrite addr fc0002a8 cmd 98 0000000000000000 64 bit x 64 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000000000000000
is= cmd 52(R) addr fc000088 is= ffffffffffffffff 0000000000000000
is= cmd 59(Y) addr fc000090 is= ffffffffffffffff 0000000000000000
fwrite addr fc002aa8 cmd 98 0000000000000000 64 bit x 64 bit
is= cmd 51(Q) addr fc000080 is= ffffffffffffffff 0000000000000000
is= cmd 52(R) addr fc000088 is= ffffffffffffffff 0000000000000000
is= cmd 59(Y) addr fc000090 is= ffffffffffffffff 0000000000000000
not found
## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
flash_protect ON: from 0xFFFC0000 to 0xFFFEE7FF
flash_protect ON: from 0xFFFA0000 to 0xFFFBFFFF
*** failed ***
### ERROR ### Please RESET the board ###
### main_loop entered: bootdelay=20



On Mon, Jan 18, 2010 at 2:15 PM, Stefan Roese <sr@denx.de> wrote:

> Hi Prakash,
>
> On Friday 15 January 2010 14:23:35 prakash bedge wrote:
> > In October 09 month, I had asked whether U-boot supports M29W128GH, a CFI
> > compilant chip and I got a yes reply. Please refer below URL for
> reference.
> >
> > http://www.mail-archive.com/u-boot at lists.denx.de/msg24531.html.
>
> Link not found. Please correct.
>
> > So I have used Uboot for my PPC440 based board.
> >
> > When I flashed U-boot on flash and then run the Uboot in DDR then U-boot
> > running on DDR fails to detect CFI chip M29W128GH (16M x 8 mode).
> >
> > flash_detect_cfi function gives error that flash not found. I have added
> > debug statements for temporary debug purpose.
> >  Please see the below error I am getting.
> >
> > The CFI query address looks different in below code and not as per ST
> make
> > M29W128GH specs. PCIMW.
>
> What's the difference then? Please give an example.
>
> I suggest you take a look at this prelimiary patch:
>
> http://lists.denx.de/pipermail/u-boot/2009-December/065562.html
>
> Please let me know if this helps or not.
>
> Cheers,
> Stefan
>
> --
> DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
>

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

[Stefan Roese]

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

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

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

[Jerry Van Baren]

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] U-boot running on DDR fails to detect the CFI compliant flash

[Wolfgang Denk]

In message <4B55BA83.4050505@ge.com> Jerry Van Baren wrote:
>
> 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 

Right.

> the problem is a simple misunderstanding of how the chip is configured 
> or the hardware is wired (beware of hardware designers doing "endian 
> fixes").

Another pretty popular trick of the hardware guys is to connect pin 0
of the data bus of the flash to pin 0 of the processor data bus, pin
1 to pin 1 etc. This gives a nice 1:1 mapping, but unfortunately not
a working system. But you should notice this already when trying to
flash you image with the JTAG probe.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Unix is simple, but it takes a genius to understand the simplicity."
					             - Dennis Ritchie

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

[prakash bedge]

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.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] U-boot running on DDR fails to detect the CFI compliant flash

[Stefan Roese]

On Tuesday 19 January 2010 17:22:33 prakash bedge wrote:
> 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

Please make sure to use the byte commands instead:

=> mw.b 0xfc000000 0xf0
=> mw.b 0xfc000055 0x98
=> md.b 0xfc000010

Otherwise you will access the FLASH 32bit wise. Please re-check with this 
version.

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

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

[Albert ARIBAUD]

prakash bedge a ?crit :
> 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?

Two things strike me as weird:

1) You're writing 32-bit words to the chip. At most it should be 16-bit 
words, possibly even 8-bits. Try mw.w and mw.b.

2) Your writes actually appear where you did them, as if the flash was 
already in write mode, which is highly unlikely, or if you had some 
cache enabled for this area of your address space.

Amicalement,
-- 
Albert.

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

[prakash bedge]

Hi Albert and Stefan,

I have used the proper commands.
i.e.
mw.b 0xfc000000 0xf0
mw.b 0xfc000055 0x98
md.b 0xfc000010
But still no positive results.
Last time I forgot to tell here, that I have commneted the for(;;) loop in
"hang" function after flash_init result testing in lib_ppc/board.c and then
I am able to run the above commands on uboot prompt.

1) You're writing 32-bit words to the chip. At most it should be 16-bit
words, possibly even 8-bits. Try mw.w and mw.b.
Prakash - I tried both but no success.
How to crosscheck the chipwidth? Can someone tell what is chipwidth and
portwidth?
I believe I am using chipwidth - 16 and portwidth - 8. How to validate this
against chipwidth and portwidth?


2) Your writes actually appear where you did them, as if the flash was
already in write mode, which is highly unlikely, or if you had some cache
enabled for this area of your address space.
Prakash - Albert, I didn't understand above message clearly. Please explain
what you want to say. If anyhow my flash is in write mode then also I should
be able to see the CFI query command response. PCIMW.


Hi Baren,

Please reply to my earlier mail addressed to you if possible.


Thanks & Regards,
Prakash Bedge
On Tue, Jan 19, 2010 at 10:14 PM, Albert ARIBAUD <albert.aribaud@free.fr>wrote:

> prakash bedge a ?crit :
>
> 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?
>>
>
> Two things strike me as weird:
>
> 1) You're writing 32-bit words to the chip. At most it should be 16-bit
> words, possibly even 8-bits. Try mw.w and mw.b.
>
> 2) Your writes actually appear where you did them, as if the flash was
> already in write mode, which is highly unlikely, or if you had some cache
> enabled for this area of your address space.
>
> Amicalement,
> --
> Albert.
>

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

[Jerry Van Baren]

Hi Prakash

Please quote properly and don't top post.  Your emails are very hard to 
understand.

prakash bedge wrote:
> Hi Albert and Stefan,
>  
> I have used the proper commands.
> i.e.
> mw.b 0xfc000000 0xf0
> mw.b 0xfc000055 0x98
> md.b 0xfc000010
> But still no positive results.
> Last time I forgot to tell here, that I have commneted the for(;;) loop 
> in "hang" function after flash_init result testing in lib_ppc/board.c 
> and then I am able to run the above commands on uboot prompt.
>  
> 1) You're writing 32-bit words to the chip. At most it should be 16-bit 
> words, possibly even 8-bits. Try mw.w and mw.b.
> Prakash - I tried both but no success.
> How to crosscheck the chipwidth? Can someone tell what is chipwidth and 
> portwidth?
> I believe I am using chipwidth - 16 and portwidth - 8. How to validate 
> this against chipwidth and portwidth?

Number one thing you *MUST* do is read the flash data sheets, especially 
the command interface.  Repeat until you understand.  Then try the QRY 
command sequence by hand in all the various possibilities (see thread 
links below).

* In your hardware, the "55" and "AA" addresses may be shifted by one or 
two bits:
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31735>

* In your hardware, the command byte lane may be one byte wide, two 
bytes wide, or four bytes wide.  This changes the 55/AA addresses and 
which byte lane(s) are used for the command.
   * Do you have 1, 2, or 4 chips on your  board?
   * Is your memory bus 1, 2, or 4 bytes wide?

The thread links below will help explain.  Note that Robert is using the 
BDI, and thus using the BDI memory read/write commands.  You want to use 
u-boot's memory read/write commands instead.

Pay special attention to these posts:
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31588>
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31723>
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31724>
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31730>
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31735>
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31787>
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31738>

Good luck,
gvb

[snip]

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

[prakash bedge]

Hi All,

At last flash detection passed. :)
I have to set one DCR register for enable flash write.

But now I am facing the debug message "flash is busy" always on save
command.
Analyzing the root cause.

Thanks all of you for your help and support.

Regards,
Prakash Bedge
On Wed, Jan 20, 2010 at 6:35 PM, Jerry Van Baren <gerald.vanbaren@ge.com>wrote:

> Hi Prakash
>
> Please quote properly and don't top post.  Your emails are very hard to
> understand.
>
>
> prakash bedge wrote:
>
>> Hi Albert and Stefan,
>>  I have used the proper commands.
>> i.e.
>> mw.b 0xfc000000 0xf0
>> mw.b 0xfc000055 0x98
>> md.b 0xfc000010
>> But still no positive results.
>> Last time I forgot to tell here, that I have commneted the for(;;) loop in
>> "hang" function after flash_init result testing in lib_ppc/board.c and then
>> I am able to run the above commands on uboot prompt.
>>  1) You're writing 32-bit words to the chip. At most it should be 16-bit
>> words, possibly even 8-bits. Try mw.w and mw.b.
>> Prakash - I tried both but no success.
>> How to crosscheck the chipwidth? Can someone tell what is chipwidth and
>> portwidth?
>> I believe I am using chipwidth - 16 and portwidth - 8. How to validate
>> this against chipwidth and portwidth?
>>
>
> Number one thing you *MUST* do is read the flash data sheets, especially
> the command interface.  Repeat until you understand.  Then try the QRY
> command sequence by hand in all the various possibilities (see thread links
> below).
>
> * In your hardware, the "55" and "AA" addresses may be shifted by one or
> two bits:
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31735>
>
> * In your hardware, the command byte lane may be one byte wide, two bytes
> wide, or four bytes wide.  This changes the 55/AA addresses and which byte
> lane(s) are used for the command.
>  * Do you have 1, 2, or 4 chips on your  board?
>  * Is your memory bus 1, 2, or 4 bytes wide?
>
> The thread links below will help explain.  Note that Robert is using the
> BDI, and thus using the BDI memory read/write commands.  You want to use
> u-boot's memory read/write commands instead.
>
> Pay special attention to these posts:
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31588>
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31723>
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31724>
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31730>
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31735>
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31787>
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31738>
>
> Good luck,
> gvb
>
> [snip]
>

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

[Francisco]

Stefan Roese <sr <at> denx.de> writes:

> 
> Hi Prakash,
> 
> On Friday 15 January 2010 14:23:35 prakash bedge wrote:
> > In October 09 month, I had asked whether U-boot supports M29W128GH, a CFI
> > compilant chip and I got a yes reply. Please refer below URL for reference.
> > 
> > http://www.mail-archive.com/u-boot <at> lists.denx.de/msg24531.html.
> 
> Link not found. Please correct.
> 
> > So I have used Uboot for my PPC440 based board.
> > 
> > When I flashed U-boot on flash and then run the Uboot in DDR then U-boot
> > running on DDR fails to detect CFI chip M29W128GH (16M x 8 mode).
> > 
> > flash_detect_cfi function gives error that flash not found. I have added
> > debug statements for temporary debug purpose.
> >  Please see the below error I am getting.
> > 
> > The CFI query address looks different in below code and not as per ST make
> > M29W128GH specs. PCIMW.
> 
> What's the difference then? Please give an example.
> 
> I suggest you take a look at this prelimiary patch:
> 
> http://lists.denx.de/pipermail/u-boot/2009-December/065562.html
> 
> Please let me know if this helps or not.
> 
> Cheers,
> Stefan
> 
> --
> DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office <at> denx.de
> 

   Hello everyone,
   Im still facing this issue with i tried to detect the M29W256G . I applied
the patch above and the code keeps on hanging in the first reset commmad. 


void __flash_cmd_reset(flash_info_t *info)
{
        /*
         * We do not yet know what kind of commandset to use, so we issue
         * the reset command in both Intel and AMD variants, in the hope
         * that AMD flash roms ignore the Intel command.
         */
        flash_write_cmd(info, 0, 0, AMD_CMD_RESET);   <<<<<----HERE it stops

        if(info->cfi_fixup & CFI_NUMONYX_FIXUP)
                return;

        udelay(1);
        flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
}
void flash_cmd_reset(flash_info_t *info)
        __attribute__((weak,alias("__flash_cmd_reset")));

static int __flash_detect_cfi (flash_info_t * info, struct cfi_qry *qry)
{
        int cfi_offset;

#define reset() writew(0x00F0, CONFIG_SYS_FLASH_BASE)
#define unlock() writel(0x00AA, CONFIG_SYS_FLASH_BASE+(0x555<<1));
writel(0x0055, CONFIG_SYS_FLASH_BASE+(0x2AA<<1))
        /* Issue FLASH reset command */
        info->cfi_fixup = 0;

#ifdef  CONFIG_FLASH_NUMONYX_FIXUP
        info->cfi_fixup = CFI_NUMONYX_FIXUP;
#endif
        flash_cmd_reset(info); 



Boot Device: SD
I2C:   ready
DRAM:   2 GB
fwc addr 08000000 cmd f0 f0 8bit x 8 bit             

  if you please could provide any hint about who to overcome this issue, I would
apprecieate it so baddly.

Regards,
Francisco