[U-Boot] NAND bad block table

[Brian Norris]

[BTW, I'm not a U-Boot subscriber, so this cross-post probably won't go through]

Hi Scott,

On Tue, Feb 11, 2014 at 4:06 PM, Scott Wood <scottwood at freescale.com> wrote:
> On Mon, 2014-02-10 at 15:05 +0000, Naveen Mamindlapalli wrote:
>> Yes, the searching of BBT happens from the end of flash when
>> NAND_BBT_USE_FLASH option is used & NAND_BBT_ABSPAGE option is not
>> used. The searching of BBT happens by scanning the last 4 blocks for
>> BBT signature starting from end block. The number of blocks to scan
>> from the end for BBT signature is defined by macro
>> NAND_BBT_SCAN_MAXBLOCKS in "include/linux/mtd/bbm.h" which is currently
>> set to value 4.
>>
>> If the last 4 blocks are factory marked bad by the vendor, then the
>> flash is not usable by u-boot or Linux. We can fix this issue by
>> changing the macro value NAND_BBT_SCAN_MAXBLOCKS to a value greater
>> than 4 (depending on the flash part) which doesn't seem to be a good
>> solution since the change has to be done to the MTD layer default
>> values.
>>
>> It would be good if there is a device tree binding to specify the
>> number of blocks to scan to check if BBT is present in the flash.
>> Currently there is no such device tree option is available.
>>
>> Thanks and Regards,
>> Naveen
>
> I see.  I wonder where the value of 4 came from -- it seems a bit small.

Not sure. The BBT uses one block for the main table and one for the
"mirror", and I assume the other two reservations were a (safe at the
time?) guess that each of those tables' eraseblock could go bad once
at some time. But yes, it's a bit small.

> The only downside of increasing NAND_BBT_SCAN_MAXBLOCKS would be a
> little extra startup latency when no BBT is present, right?

No, it also means you can no longer use those blocks for anything
else. MTD reserves them and pretends they are bad so that no one can
place data there. MTD reserves the right to reclaim any of these
blocks if one of the other BBT blocks goes bad.

As a consequence, increasing this macro potentially can break people's
existing systems if they upgrade kernels. If they were using the N-5th
block for data and you increase NAND_BBT_SCAN_MAXBLOCKS, the user
suddenly lost their data.

The NAND BBT could really use some improvements in this regard.
Perhaps a DT property is a start, so that users can specify this
parameter portably across kernel versions. But perhaps nand_bbt could
also use some work to decouple the maximum # of blocks to scan from
the act of a-priori "reserving" of blocks. It's a difficult question
to reason out, as you don't want to block the user from utilizing too
much of the flash. (And please note that we should carefully consider
the latter problem before going forward with a DT binding; it may turn
out that committing to a "max # of reserved BBT blocks" property won't
exactly make sense if we want a more comprehensive solution to this
problem.)

Brian