From: Peter Barada <peter.barada@logicpd.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] NAND flash question
Date: Mon, 23 Sep 2013 13:02:12 -0400 [thread overview]
Message-ID: <52407414.7050805@logicpd.com> (raw)
In-Reply-To: <F9C551623D2CBB4C9488801D14F864C639AD1190@ex-mb1.corp.adtran.com>
On 09/20/2013 11:27 AM, ANDY KENNEDY wrote:
>> -----Original Message-----
>> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Peter Barada
>> Sent: Thursday, September 19, 2013 3:26 PM
>> To: u-boot at lists.denx.de; Peter Barada
>> Subject: Re: [U-Boot] NAND flash question
>>
>> On 09/19/2013 04:04 PM, ANDY KENNEDY wrote:
>>> All,
>>>
>>> We have a design that has NAND as a secondary device (not the boot
>>> device). The last four pages of the NAND flash are reported as bad.
>>> Should this be true for all NAND flash devices we have?
>>>
>>>
>> No, I wouldn't think so. Manufacturers qualify their parts and mark bad
>> blocks found during qualification testing. Most data sheets indicate
>> that the number of bad blocks marked bad during manufacturer is below a
>> set percentage(if above thent he part is rejected). Some parts that are
>> meant to be used during boot (such as NAND meant for OMAP parts) will
>> have certain blocks that are guaranteed good (i.e. the boot blocks).
>> Past that bad blocks could be anywhere in a particular device.
>>
> Okay, well, next question: So on EVERY unit we have designed with a
> NAND flash, when u-Boot reads the NAND flash it reports that it couldn't
> locate a bad block table and states that it cannot read the last four
> pages of the flash. Next, when one does a 'nand bad' on these boards,
> these last four pages are reported by u-Boot as bad. Looking at the
> code, we believe that this is by design. Is that correct? Has anyone
> else done a 'nand bad' on a board and seen the same information?
>
> Thanks again for any information you can provide,
>
> Andy
If you are using a NAND-based bad block table (i.e. set the
NAND_USE_FLASH_BBT bit in nand->options), then the MTD layer will
internally use the last four blocks to hold the bad block table _and_
report those blocks as bad to prevent the user from accidentally
modifying them...
--
Peter Barada
peter.barada at logicpd.com
prev parent reply other threads:[~2013-09-23 17:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-19 20:04 [U-Boot] NAND flash question ANDY KENNEDY
2013-09-19 20:25 ` Peter Barada
2013-09-20 15:27 ` ANDY KENNEDY
2013-09-23 17:02 ` Peter Barada [this message]
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=52407414.7050805@logicpd.com \
--to=peter.barada@logicpd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.