[PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips
avorontsov at ru.mvista.com
Fri Jun 27 11:04:30 EDT 2008
On Fri, Jun 27, 2008 at 09:43:28AM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> On Thu, Jun 26, 2008 at 01:59:45PM -0500, Scott Wood wrote:
>>> Anton Vorontsov wrote:
>>>> For large page chips, nand_bbt is looking into OOB area, and checking
>>>> for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be
>>>> reserved for bbt means.
>>> Interesting... both the 8313 manual and the manual for a random large
>>> page NAND chip say that the bad block indicator is one byte.
>> Ok, great. If I understood David correctly, second byte is used (by some
>> chips?) for redundancy, thus should not be a big problem if we'll ignore
>> it. So, would you ack this part? Then I'll resend it with some typos
>> fixed. ;-)
> Acked-by: Scott Wood <scottwood at freescale.com>
Thanks, but it seems we can't ignore the second byte. :-( See the patch
I just sent.
>>> BTW, I was just looking at NAND boot on this chip, and it seems that
>>> it expects ECCM=1 for large page devices, so we should make that the
>>> default (preferably at the same time as we fix this problem, so that
>>> we don't break compatibility with a working version).
>> Ugh. I think driver should support both. If we'll change (force) this in
>> Linux, we'll break older u-boots (especially FSL U-Boots with NAND
>> support enabled).
> I'm not aware of a Freescale board with large page NAND...
MPC8610HPCD comes with 1*4GB LP NAND.
>> I believe that simply changing ECCM to 1 in the newer
>> community u-boots would be less pain for everybody, no?
> OK, though we'll have to load the existing FMR[ECCM] into priv->fmr on
> init, rather than starting with zero.
Yeah. But this is another issue.
email: cbouatmailru at gmail.com
More information about the linux-mtd