On Freitag, 26. Februar 2010, Alberto Panizzo wrote:

On ven, 2010-02-26 at 12:48 +0100, Juergen Beisert wrote:

quoted

Hi Alberto,

Alberto Panizzo wrote:

quoted

On ven, 2010-02-26 at 10:56 +0100, Juergen Beisert wrote:

quoted

Fabio Estevam wrote:

quoted

quoted

Are you sure that this works? Don't you see a lot of Bad
blocks reports
in boot messages?

I followed the same approach used on other i.MX boards. This is
what I see: ...
NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND
256MiB 1,8V 8-bit) Scanning device for bad blocks
Bad eraseblock 42 at 0x000000540000
Bad eraseblock 125 at 0x000000fa0000
Bad eraseblock 887 at 0x000006ee0000
Bad eraseblock 1750 at 0x00000dac0000
Bad eraseblock 2046 at 0x00000ffc0000
Bad eraseblock 2047 at 0x00000ffe0000
Registering mxc_nand as whole device

If I define it as:

static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
	.width = 1,
	.hw_ecc = 1,
	.flash_bbt =1,
};

Your bootloader also use a Bad Block Table? Then also your kernel
should use it. If hardware ECC is in use, its always a good idea to
collect the bad blocks into a BBT. Most of the time you can't control
at which offset in the OOB data the NAND controller will store the
ECC sum. There is the risk it will destroy manufacturer's bad block
markers. So, its better to collect these marked bad blocks into a BBT
the first time you use the NAND device. After that _only_ the BBT
should be used to handle bad blocks (in the boot loader and the
kernel).

Thank you Juergen to participate on this thread.
Ok, so with this board shall be enabled the flash_bbt checking because
the bootloader uses it. But how do you explain that on Mine board the
kernel recognize it correctly and in Fabio's board the kernel prompt
disagree with the bootloader one? It is a kind of bootloader issue?

Here on my i.MX35 based system the bootloader reports:

NAND device: Manufacturer ID: 0x20, Chip ID: 0xac (ST Micro NAND 512MiB
1,8V 8-bit) Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
nand_read_bbt: Bad block at 0x01d00000
nand_read_bbt: Bad block at 0x10020000
nand_read_bbt: Bad block at 0x10040000
nand_read_bbt: Bad block at 0x10060000
nand_read_bbt: Bad block at 0x10080000
nand_read_bbt: Bad block at 0x100a0000
nand_read_bbt: Bad block at 0x100e0000
nand_read_bbt: Bad block at 0x10120000
nand_read_bbt: Bad block at 0x10160000
nand_read_bbt: Bad block at 0x101a0000
nand_read_bbt: Bad block at 0x101c0000
nand_read_bbt: Bad block at 0x10200000
nand_read_bbt: Bad block at 0x10240000

And the starting kernel reports:

[...]
NAND device: Manufacturer ID: 0x20, Chip ID: 0xac (ST Micro NAND 512MiB
1,8V 8-bit) Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
nand_read_bbt: Bad block at 0x000001d00000
nand_read_bbt: Bad block at 0x000010020000
nand_read_bbt: Bad block at 0x000010040000
nand_read_bbt: Bad block at 0x000010060000
nand_read_bbt: Bad block at 0x000010080000
nand_read_bbt: Bad block at 0x0000100a0000
nand_read_bbt: Bad block at 0x0000100e0000
nand_read_bbt: Bad block at 0x000010120000
nand_read_bbt: Bad block at 0x000010160000
nand_read_bbt: Bad block at 0x0000101a0000
nand_read_bbt: Bad block at 0x0000101c0000
nand_read_bbt: Bad block at 0x000010200000
nand_read_bbt: Bad block at 0x000010240000
[...]

Both are configured to use a BBT and will handle the bad blocks in the
same manner.

Regards,
Juergen

Well, also for me. With Bbt active:

++Searching for BBT table in the flash ...
.
Found version 1 Bbt0 at block 2047 (0xffe0000)
Block 55 is bad
Block 1688 is bad
Block 1735 is bad
Block 1742 is bad
Total bad blocks: 4
... Read from 0x07ee0000-0x07f00000 at 0x00080000: ..
... Read from 0x07ed3000-0x07ed4000 at 0x0009f000: .
PMIC ID: 0x0000009b [Rev: 3.3]

...

NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V
8-b) Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: Bad block at 0x0000006e0000
nand_read_bbt: Bad block at 0x00000d300000
nand_read_bbt: Bad block at 0x00000d8e0000
nand_read_bbt: Bad block at 0x00000d9c0000

That considering a block size of 64 pages, it is consistent.

But without bad block table enabled:

NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V
8-b) Scanning device for bad blocks
Bad eraseblock 4 at 0x000000080000
Bad eraseblock 8 at 0x000000100000
Bad eraseblock 9 at 0x000000120000
Bad eraseblock 10 at 0x000000140000
Bad eraseblock 11 at 0x000000160000
Bad eraseblock 12 at 0x000000180000
all blocks..
Bad eraseblock 342 at 0x000002ac0000
Bad eraseblock 1688 at 0x00000d300000
Bad eraseblock 1735 at 0x00000d8e0000
Bad eraseblock 1742 at 0x00000d9c0000
Bad eraseblock 2046 at 0x00000ffc0000
Bad eraseblock 2047 at 0x00000ffe0000

All blocks went bad.
I had seen this behaviour developing the machine support for the
Armadillo500 board, and that was solved by updating the ecc layout
management due to bad 2K page sized NAND flash support.
With the new version (V2) of the driver this comes back..

Maybe you previously used a driver that does not report the byte at offset 5 
in the OOB as used (for 512 byte page size). So this byte was used (maybe) by 
jffs2 for example. When you switch off the BBT now, all these blocks seems 
marked as bad, because then byte 5 will be used again. For 2k page size, the 
bad block information is stored in byte 0 and 1 in the OOB. And maybe the 
same happend to these bytes by an old driver.

Regards,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | Phone: +49-8766-939 228     |
Vertretung Sued/Muenchen, Germany             | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686              | http://www.pengutronix.de/  |