From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Tue, 28 Feb 2012 17:40:47 -0600
Subject: [U-Boot] Nand dump and nand bad block disagree
In-Reply-To: <CAGGh5h0j-UG8kr6CRJsqbPPWwws==KLS7JBR6Kv=wogCT0Kfgw@mail.gmail.com>
References: <CAGGh5h0j-UG8kr6CRJsqbPPWwws==KLS7JBR6Kv=wogCT0Kfgw@mail.gmail.com>
Message-ID: <4F4D65FF.4070700@freescale.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 02/28/2012 08:34 AM, jean-philippe francois wrote:
> Hi,
> 
> I have an omap3 based board with a micron 4Gbit large page nand attached.
> when using software ecc, everything is fine.
> 
> When using hardware ecc, ecc is ok (ie u-boot and ROM bootloader agree),
> but bad block detection is broken.
> 
> Here is an OOB dump
> OOB:
> 	ff 44 bb 1e ba 45 87 f7
> 	f7 88 38 c7 d2 ff ff ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff ff ff ff ff ff ff
> 
> According to the code in drivers/mtd/nand_base.c, bad block checking
> is done by reading OOB data at a particular position. For large page,
> this is at NAND_LARGE_BADBLOCK_POS which is zero.
> 
> In the above OOB data, oob[0] is 0xff, so there is no reason
> for this block to be considered as bad. How can I sort this ?

Is this a 16-bit NAND?  If so, the first two bytes have to be 0xffff,
unless the controller driver defines the bad block pattern differently.

Also please mention which version of U-Boot you're using.  Top of tree
currently has broken nand dump (fixed with the latest nand pull request).

-Scott