[U-Boot] NAND bad block table

[U-Boot] NAND bad block table

[Michal Simek]

Hi Scott and others,

I have a question regarding BBT position and number of blocks allocated
for BBT.

Did you face the issue with last 4 blocks broken in any NAND flash
device since the default option in Linux/u-boot BBM is last 4 blocks?

It doesn't mean that if the last 4 blocks are broken than the NAND flash
device is broken too.
Also I haven't seen any common binding for Linux kernel to change it.

Has someone tried to improve this algorithm or process of storing BBT in a better way.
For example just look for BBT from the end till any limit?

Thanks,
Michal

[U-Boot] NAND bad block table

[Scott Wood]

On Tue, 2014-02-04 at 13:43 +0100, Michal Simek wrote:
> Hi Scott and others,
> 
> I have a question regarding BBT position and number of blocks allocated
> for BBT.
> 
> Did you face the issue with last 4 blocks broken in any NAND flash
> device since the default option in Linux/u-boot BBM is last 4 blocks?
> 
> It doesn't mean that if the last 4 blocks are broken than the NAND flash
> device is broken too.
> Also I haven't seen any common binding for Linux kernel to change it.
> 
> Has someone tried to improve this algorithm or process of storing BBT in a better way.
> For example just look for BBT from the end till any limit?

I don't recall if I've ever tested it personally, but that sort of
scanning is already there.  Have you seen a problem with it?

-Scott

[U-Boot] NAND bad block table

[Michal Simek]

On 02/04/2014 09:46 PM, Scott Wood wrote:
> On Tue, 2014-02-04 at 13:43 +0100, Michal Simek wrote:
>> Hi Scott and others,
>>
>> I have a question regarding BBT position and number of blocks allocated
>> for BBT.
>>
>> Did you face the issue with last 4 blocks broken in any NAND flash
>> device since the default option in Linux/u-boot BBM is last 4 blocks?
>>
>> It doesn't mean that if the last 4 blocks are broken than the NAND flash
>> device is broken too.
>> Also I haven't seen any common binding for Linux kernel to change it.
>>
>> Has someone tried to improve this algorithm or process of storing BBT in a better way.
>> For example just look for BBT from the end till any limit?
> 
> I don't recall if I've ever tested it personally, but that sort of
> scanning is already there.  Have you seen a problem with it?

We have met with nand device which has broken last 4 blocks and
u-boot and linux just scan last 4 blocks by default.

In connection to Linux. Interesting is that there is no binding
for extending scan blocks and this has to be done through driver
properties.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140205/495764b8/attachment.pgp>

[U-Boot] NAND bad block table

[Scott Wood]

On Wed, 2014-02-05 at 15:16 +0100, Michal Simek wrote:
> On 02/04/2014 09:46 PM, Scott Wood wrote:
> > On Tue, 2014-02-04 at 13:43 +0100, Michal Simek wrote:
> >> Hi Scott and others,
> >>
> >> I have a question regarding BBT position and number of blocks allocated
> >> for BBT.
> >>
> >> Did you face the issue with last 4 blocks broken in any NAND flash
> >> device since the default option in Linux/u-boot BBM is last 4 blocks?
> >>
> >> It doesn't mean that if the last 4 blocks are broken than the NAND flash
> >> device is broken too.
> >> Also I haven't seen any common binding for Linux kernel to change it.
> >>
> >> Has someone tried to improve this algorithm or process of storing BBT in a better way.
> >> For example just look for BBT from the end till any limit?
> > 
> > I don't recall if I've ever tested it personally, but that sort of
> > scanning is already there.  Have you seen a problem with it?
> 
> We have met with nand device which has broken last 4 blocks and
> u-boot and linux just scan last 4 blocks by default.
> 
> In connection to Linux. Interesting is that there is no binding
> for extending scan blocks and this has to be done through driver
> properties.

Could you be more specific about what sort of "driver property" you're
talking about?  AFAICT from glancing at the code, searching is the
default unless the controller driver specifies NAND_BBT_ABSPAGE.

In any case, this code comes straight from Linux, so you'll probably
find people more familiar with this code on linux-mtd.

-Scott

[U-Boot] NAND bad block table

[Scott Wood]

On Mon, 2014-02-10 at 15:05 +0000, Naveen Mamindlapalli wrote:
> Cc: linux-mtd-list
> 
> Hi Scott,
> 
> 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.
The only downside of increasing NAND_BBT_SCAN_MAXBLOCKS would be a
little extra startup latency when no BBT is present, right?

-Scott

[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@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