public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] NAND bad block table
Date: Tue, 11 Feb 2014 18:06:10 -0600	[thread overview]
Message-ID: <1392163570.6733.409.camel@snotra.buserror.net> (raw)
In-Reply-To: <155aac48-cedd-4daa-80b0-577f85080950@CO1EHSMHS005.ehs.local>

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

  parent reply	other threads:[~2014-02-12  0:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-04 12:43 [U-Boot] NAND bad block table Michal Simek
2014-02-04 20:46 ` Scott Wood
2014-02-05 14:16   ` Michal Simek
2014-02-05 19:16     ` Scott Wood
     [not found]       ` <155aac48-cedd-4daa-80b0-577f85080950@CO1EHSMHS005.ehs.local>
2014-02-12  0:06         ` Scott Wood [this message]
2014-02-12  0:47           ` Brian Norris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1392163570.6733.409.camel@snotra.buserror.net \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox