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

Alemao xcarandiru at gmail.com
Wed Aug 27 16:52:48 CEST 2008


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


More information about the U-Boot mailing list