[U-Boot-Users] NAND: bad block in whole chip

[U-Boot-Users] NAND: bad block in whole chip

[Alemao]

Hi all,

Im trying to use my NAND flash at MPC8360E-RDK based board.
But it seems that the whole chip is bad blocked.
Dont know if Im missing something... below some outputs:

=> nand info

Device 0: NAND 64MiB 3,3V 8-bit, sector size 16 KiB

=> nand bad
  00000000
  00004000
     .
     .
     .
  03ff4000
  03ff8000
  03ffc000
=> nand erase clean

NAND erase: device 0 whole chip
Skipping bad block at  0x00000000
Skipping bad block at  0x00004000
             .
             .
             .
Skipping bad block at  0x03ff8000
Skipping bad block at  0x03ffc000

OK
=>

I read that any block that contains bytes != 0xff in the OOB is
marked as "factory bad" block.

At nand_block_bad() function (drivers/nand/nand_base.c) I saw the
implementation of the statment above.

---
this->cmdfunc (mtd, NAND_CMD_READOOB, this->badblockpos, page);
		
if (this->read_byte(mtd) != 0xff) res = 1;
---


So I did some dumps in NAND:


=> nand dump 0x00004000
Page 0x00004000 dump:
             .
             .
             .
OOB:
        00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00

=> nand dump 0x03ff8000
Page 03ff8000 dump:
             .
             .
             .
OOB:
        81 81 81 01 81 81 81 81
        81 81 81 81 81 81 81 81


All dumps had OOB != 0xff

I also tried to write only 1 byte... no success:

=> tftpboot 0x02000000 kernel_blob.img
=> nand write.jffs2 0x02000000 0x0 0x1
   .
   .
   .
Bad block at 0x2010000 in erase block from 0x2010000 will be skipped
writing NAND page at offset 0x2014000 failed
Data did not fit into device, due to bad blocks
 1 bytes written: ERROR
=>


Any help/suggestions welcome.


Im using U-Boot-1.1.4 with NAND and FSL_UPM drivers from U-Boot-1.3.3

Cheers,

--
Alemao

[U-Boot] NAND: bad block in whole chip

[Alemao]

Hi all,

Im trying to use my NAND flash at MPC8360E-RDK based board.
But it seems that the whole chip is bad blocked.
Dont know if Im missing something... below some outputs:

=> nand info

Device 0: NAND 64MiB 3,3V 8-bit, sector size 16 KiB

=> nand bad
 00000000
 00004000
    .
    .
    .
 03ff4000
 03ff8000
 03ffc000
=> nand erase clean

NAND erase: device 0 whole chip
Skipping bad block at  0x00000000
Skipping bad block at  0x00004000
            .
            .
            .
Skipping bad block at  0x03ff8000
Skipping bad block at  0x03ffc000

OK
=>

I read that any block that contains bytes != 0xff in the OOB is
marked as "factory bad" block.

At nand_block_bad() function (drivers/nand/nand_base.c) I saw the
implementation of the statment above.

---
this->cmdfunc (mtd, NAND_CMD_READOOB, this->badblockpos, page);

if (this->read_byte(mtd) != 0xff) res = 1;
---


So I did some dumps in NAND:


=> nand dump 0x00004000
Page 0x00004000 dump:
            .
            .
            .
OOB:
       00 00 00 00 00 00 00 00
       00 00 00 00 00 00 00 00

=> nand dump 0x03ff8000
Page 03ff8000 dump:
            .
            .
            .
OOB:
       81 81 81 01 81 81 81 81
       81 81 81 81 81 81 81 81


All dumps had OOB != 0xff

I also tried to write only 1 byte... no success:

=> tftpboot 0x02000000 kernel_blob.img
=> nand write.jffs2 0x02000000 0x0 0x1
  .
  .
  .
Bad block at 0x2010000 in erase block from 0x2010000 will be skipped
writing NAND page at offset 0x2014000 failed
Data did not fit into device, due to bad blocks
 1 bytes written: ERROR
=>


Any help/suggestions welcome.


Im using U-Boot-1.1.4 with NAND and FSL_UPM drivers from U-Boot-1.3.3

Cheers,

--
Alemao

[U-Boot] NAND: bad block in whole chip

[Scott Wood]

Alemao wrote:
> Hi all,
> 
> Im trying to use my NAND flash at MPC8360E-RDK based board.
> But it seems that the whole chip is bad blocked.
> Dont know if Im missing something... below some outputs:

Odds are that something is broken in the NAND driver, and you're reading 
garbage.

> Any help/suggestions welcome.
> 
> 
> Im using U-Boot-1.1.4 with NAND and FSL_UPM drivers from U-Boot-1.3.3

Try using the latest u-boot.

-Scott

[U-Boot] NAND: bad block in whole chip

[Alemao]

Now i got all NAND stuffs from u-boot-1.3.4, including common/cmd_nand.c
and drivers/mtd/nand/*, but still the same problem.

Other components of u-boot can influence NAND behavior?

I saw some people with similar problem using "nand scrub", but im little
bit afraid with this command...

Another thing i notice: when reseting the board without turning off
power, NAND is not found.

Cheers,

--
Alemao


On Tue, Aug 12, 2008 at 2:57 PM, Scott Wood <scottwood@freescale.com> wrote:
> Alemao wrote:
>>
>> Hi all,
>>
>> Im trying to use my NAND flash at MPC8360E-RDK based board.
>> But it seems that the whole chip is bad blocked.
>> Dont know if Im missing something... below some outputs:
>
> Odds are that something is broken in the NAND driver, and you're reading
> garbage.
>
>> Any help/suggestions welcome.
>>
>>
>> Im using U-Boot-1.1.4 with NAND and FSL_UPM drivers from U-Boot-1.3.3
>
> Try using the latest u-boot.
>
> -Scott
>

[U-Boot] NAND: bad block in whole chip

[Darrik Spaude]

When I had discovered that my NAND flash had all bad blocks, I found a
patch to dump the NAND blocks (which I think you had said you did). What
I found in my case was that on one board 8 data lines were disconnected
and on another one of the 0 ohm resistors was faulty (so one bit was
always read as 0).

Might you have a hardware problem with your NAND? Who is the
manufacturer of the NAND chip, what is its part number, and does u-boot
have that part and its ID listed as a supported device?

Darrik

------------

Now i got all NAND stuffs from u-boot-1.3.4, including common/cmd_nand.c
and drivers/mtd/nand/*, but still the same problem.

Other components of u-boot can influence NAND behavior?

I saw some people with similar problem using "nand scrub", but im little
bit afraid with this command...

Another thing i notice: when reseting the board without turning off
power, NAND is not found.

[U-Boot] NAND: bad block in whole chip

[Stefan Roese]

On Wednesday 13 August 2008, Alemao wrote:
> Now i got all NAND stuffs from u-boot-1.3.4, including common/cmd_nand.c
> and drivers/mtd/nand/*, but still the same problem.
>
> Other components of u-boot can influence NAND behavior?
>
> I saw some people with similar problem using "nand scrub", but im little
> bit afraid with this command...

Yes, you should be. Be careful with this command.

Note that in all cases where I read all NAND blocks as bad, either the NAND 
driver had a problem or the hardware had a problem. Are you sure that the 
hardware is ok?

Best regards,
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] NAND: bad block in whole chip

[Alemao]

Dont know if can be a hardware problem, cause NAND is found in localbus:

I just copy/paste nand_scan code (from nand_base.c) and try this:

With u-boot-1.1.4 + drivers from u-boot-1.3.4:

DDR RAM: 128 MB
FLASH: 16 MB
In:    serial
Out:   serial
Err:   serial
NAND:  64 MiB

=> nand scan

        Maf. ID: 0x00   -   Dev. ID: 0x00
=> nand scan

        Maf. ID: 0x20   -   Dev. ID: 0x76
=> nand scan

        Maf. ID: 0x00   -   Dev. ID: 0x00
=> nand scan

        Maf. ID: 0x20   -   Dev. ID: 0x76


Maf. ID: 0x20, Dev. ID: 0x76: the right nand, NAND512W3A2BN6E from STMICRO

And if I use another command like "nand bad", then I got just 0x00 in
all other "nand scan" commands.


Now with u-boot-1.1.4 + drivers from first upm release:

DDR RAM: 128 MB
FLASH: 16 MB
In:    serial
Out:   serial
Err:   serial
NAND:  64 MiB

=> nand scan

        Maf. ID: 0x00   -   Dev. ID: 0x00
=> nand scan

        Maf. ID: 0x00   -   Dev. ID: 0x00
=> nand scan

        Maf. ID: 0x00   -   Dev. ID: 0x00
=> nand scan

        Maf. ID: 0x00   -   Dev. ID: 0x00


0x00 in all tries.

Each version cause a different behavior, so not sure if can be hardware

Cheers,

--
Alemao
On Wed, Aug 13, 2008 at 11:44 AM, Stefan Roese <sr@denx.de> wrote:
> On Wednesday 13 August 2008, Alemao wrote:
>> Now i got all NAND stuffs from u-boot-1.3.4, including common/cmd_nand.c
>> and drivers/mtd/nand/*, but still the same problem.
>>
>> Other components of u-boot can influence NAND behavior?
>>
>> I saw some people with similar problem using "nand scrub", but im little
>> bit afraid with this command...
>
> Yes, you should be. Be careful with this command.
>
> Note that in all cases where I read all NAND blocks as bad, either the NAND
> driver had a problem or the hardware had a problem. Are you sure that the
> hardware is ok?
>
> Best regards,
> 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] NAND: bad block in whole chip

[Alemao]

Hi,

Continuing with NAND problems...

I replaced:

#define CFG_LCRR   (LCRR_DBYP | LCRR_CLKDIV_4)

by:

#define CFG_LCRR   (LCRR_DBYP | LCRR_CLKDIV_8)


And now I can read and there is only one bad block, but no erase or write yet:
(I checked WP and its correct, 3.3V)


=> nand read.jffs2 0x02000000 4000 4000

NAND read: device 0 offset 0x4000, size 0x4000

Reading data from 0x7e00 -- 100% complete.
 16384 bytes read: OK
=>


=> nand unlock 4000 8000
device 0 offset 0x4000, size 0x8000
nand_unlock: start: 00004000, length: 32768!
Error unlocking NAND flash, write and erase will probably fail
=>


=> nand lock status
device is NOT write protected
00000000 - 03fffdff:   131071 pages TIGHT LOCK UNLOCK
=>


=> nand write.jffs2 0x02000000 4000 4000

NAND write: device 0 offset 0x4000, size 0x4000

writing NAND page at offset 0x4000 failed
Data did not fit into device, due to bad blocks
 16384 bytes written: ERROR
=>


=> nand info

Device 0: NAND 64MiB 3,3V 8-bit, sector size 16 KiB
=>

=> nand bad

Device 0 bad blocks:
  00000000
=>


=> nand erase clean 4000 4000

NAND erase: device 0 offset 0x4000, size 0x4000

NAND 64MiB 3,3V 8-bit: MTD Erase failure: -5

OK
=>


My board is based on MPC8360E-RDK, but I found one difference:

MPC8360E-RDK is running at 667 Mhz and mine is at 500 Mhz (CSB: 333 MHz)

Could this influence local bus timming?


Cheers,

--
Alemao


On Thu, Aug 14, 2008 at 2:22 PM, Alemao <xcarandiru@gmail.com> wrote:
> Dont know if can be a hardware problem, cause NAND is found in localbus:
>
> I just copy/paste nand_scan code (from nand_base.c) and try this:
>
> With u-boot-1.1.4 + drivers from u-boot-1.3.4:
>
> DDR RAM: 128 MB
> FLASH: 16 MB
> In:    serial
> Out:   serial
> Err:   serial
> NAND:  64 MiB
>
> => nand scan
>
>        Maf. ID: 0x00   -   Dev. ID: 0x00
> => nand scan
>
>        Maf. ID: 0x20   -   Dev. ID: 0x76
> => nand scan
>
>        Maf. ID: 0x00   -   Dev. ID: 0x00
> => nand scan
>
>        Maf. ID: 0x20   -   Dev. ID: 0x76
>
>
> Maf. ID: 0x20, Dev. ID: 0x76: the right nand, NAND512W3A2BN6E from STMICRO
>
> And if I use another command like "nand bad", then I got just 0x00 in
> all other "nand scan" commands.
>
>
> Now with u-boot-1.1.4 + drivers from first upm release:
>
> DDR RAM: 128 MB
> FLASH: 16 MB
> In:    serial
> Out:   serial
> Err:   serial
> NAND:  64 MiB
>
> => nand scan
>
>        Maf. ID: 0x00   -   Dev. ID: 0x00
> => nand scan
>
>        Maf. ID: 0x00   -   Dev. ID: 0x00
> => nand scan
>
>        Maf. ID: 0x00   -   Dev. ID: 0x00
> => nand scan
>
>        Maf. ID: 0x00   -   Dev. ID: 0x00
>
>
> 0x00 in all tries.
>
> Each version cause a different behavior, so not sure if can be hardware
>
> Cheers,
>
> --
> Alemao
> On Wed, Aug 13, 2008 at 11:44 AM, Stefan Roese <sr@denx.de> wrote:
>> On Wednesday 13 August 2008, Alemao wrote:
>>> Now i got all NAND stuffs from u-boot-1.3.4, including common/cmd_nand.c
>>> and drivers/mtd/nand/*, but still the same problem.
>>>
>>> Other components of u-boot can influence NAND behavior?
>>>
>>> I saw some people with similar problem using "nand scrub", but im little
>>> bit afraid with this command...
>>
>> Yes, you should be. Be careful with this command.
>>
>> Note that in all cases where I read all NAND blocks as bad, either the NAND
>> driver had a problem or the hardware had a problem. Are you sure that the
>> hardware is ok?
>>
>> Best regards,
>> 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
>> =====================================================================
>>
>