[U-Boot-Users] NAND: bad block in whole chip
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
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
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
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
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@denx.de =====================================================================
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@denx.de =====================================================================
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: 0x76Maf. 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: 0x000x00 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@denx.de =====================================================================
participants (3)
-
Alemao -
Scott Wood -
Stefan Roese