Re: [RFC] mtd: nand: separate chip options / bbt_options

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

Brian Norris wrote:
> Hi,
Hi Brian,

> On Fri, Apr 22, 2011 at 1:02 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>> On Wed, 2011-04-20 at 00:13 -0700, Brian Norris wrote:
>>> Other things to consider (not yet implemented):
>>> * Is it safe to move NAND_CREATE_EMPTY_BBT to bbm.h and require it to be
>>>   put in bbt_options? It seems not to be used by any in-kernel drivers
>>>   so it's only likely to mess with independent drivers...
>> What exactly this option mean and how could it be used?
> 
> I'm not entirely sure how it would be used (perhaps ask Sebastian, the
> one who introduced it in commit 453281a9), but I have an idea what it
> means.
> 
> It seems that (when combined with NAND_BBT_CREATE) this flag causes
> nand_scan_bbt() / check_create() to skip the scanning portion of
> creating a bad block table, effectively leaving an empty bad block
> table. According to the commit message:
>     it will create an empty BBT table without considering vendor's BBT
>     information. Vendor's information may be unavailable if the NAND
>     controller has a different DATA & OOB layout or this information may be
>     allready purged.
> 
> I'm prepared to simply move this over to bbm.h (next to
> NAND_BBT_CREATE) if it's worth saving. Otherwise, it can just as
> easily be dumped.

It is kinda required here :) The long story:
The NAND-controller needs the complete OOB area for ECC. So we have no
room for BBT in OOB. Therefore we use BBT table on flash without the
recognition marking in the OOB area.
This option (NAND_CREATE_EMPTY_BBT) is used to have an empty BBT table on
the first scan. The reason is that the boards are in-some kind production
test before I got them and the format which is used there is unknown and
Vendor's (Nand-chip Vendor) BBT information in OOB is lost. On the second
scan we use the on-flash BBT information (which is created by mtd) so it
is not empty again.

> 
> Brian

Sebastian