public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Frans Meulenbroeks <fransmeulenbroeks@yahoo.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] NAND bad environment block handling
Date: Thu, 8 Jan 2009 23:25:15 -0800 (PST)	[thread overview]
Message-ID: <127097.50795.qm@web33604.mail.mud.yahoo.com> (raw)
In-Reply-To: <1E2B849CC9AB394DBEC29714EBD02F503C2DF9@mtlms3.Co.Corp.VerintSystems.com>

Sylvain, Scott,

Thanks for the info.
If the bad env blocks are skipped that at least would solve my problem.
I hope that it does not break fw_setenv. 
Storing the pointer in oob in block 0 is an interesting idea. I need to think about the impact on that one a little bit more.

With large blocks definitely the waste is big. Ideal solution would be that the hw does bad block mapping. Somewhat less ideal would be to position partitions dynamically  and specify the mtd partition start points at the kernel cmd line. Issue is that this is complicates the software upgrade. Even less ideal but common practice today seems to be to reserve slack room for every partition (or even worse, ignore the problem and assume perfect NAND)

Best regards, Frans


--- On Thu, 1/8/09, Cote, Sylvain <Sylvain.Cote@verint.com> wrote:

> From: Cote, Sylvain <Sylvain.Cote@verint.com>
> Subject: RE: [U-Boot] NAND bad environment block handling
> To: fransmeulenbroeks at yahoo.com, u-boot at lists.denx.de
> Date: Thursday, January 8, 2009, 5:06 PM
> My understanding is that u-boot already support bad block
> for the environment config.   When reading or writing the
> config from/to the nand, u-boot skip bad block.  However,
> you need to reserve some spare blocks in nand for
> environment config.  This is done in u-boot-nand.lds:
> 
> /* Align to next NAND block.  The NAND has block of 128K
> ==> 0x20000*/
>     . = ALIGN(0x20000);
>     common/environment.o  (.ppcenv)
>     /* Keep some space here for redundant env and potential
> bad env blocks */
>     . = ALIGN(0x80000);
> 
> 
> Regards 
> 
> Sylvain C?t?
> 
> -----Original Message-----
> From: u-boot-bounces at lists.denx.de
> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Frans
> Meulenbroeks
> Sent: Thursday, January 08, 2009 10:19 AM
> To: u-boot at lists.denx.de
> Subject: [U-Boot] NAND bad environment block handling
> 
> Hi,
> 
> I'm wondering what the best way is to handle bad
> environment blocks in NAND.
> 
> According to the spec of our supplier a delivered component
> is considered to be OK if less than 2% of the blocks are not
> bad.
> This means that for our products we need to take into
> account that worst case 2% of the blocks are bad. But even
> with 1% bad blocks we have an issue:
> If the bad blocks are distributed randomly we have a chance
> of 1/100 * 1/100 so 1 out of 10.000 that both U-Boot
> environment blocks are bad. 
> And actually things could even be worse if the bad blocks
> are caused by some manufacturing defect at our supplier and
> both environment blocks happen to be bad in a whole batch of
> ICs.
> 
> Is there a solution for this?
> (obviously I am not considering the situation for a single
> system, where I just would relocate the environment block;
> this concerns a production situation).
> 
> E.g. it would be nice if U-Boot could read the env from the
> next non-bad block at/after the env address.
> 
> Has someone experience in this area? Ideas? Suggestions?
> 
> Thanks alot!
> Frans Meulenbroeks
> 
> 
>       
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot


      

  reply	other threads:[~2009-01-09  7:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-08 15:19 [U-Boot] NAND bad environment block handling Frans Meulenbroeks
2009-01-08 16:06 ` Cote, Sylvain
2009-01-09  7:25   ` Frans Meulenbroeks [this message]
2009-01-08 19:57 ` Scott Wood
2009-01-09  7:21   ` Marcel Ziswiler
2009-01-09 21:23     ` Wolfgang Denk
2009-01-11 11:10 ` Schlaegl Manfred jun.
2009-01-11 13:26   ` Frans Meulenbroeks
2009-01-11 20:20     ` Schlaegl Manfred jun.
2009-01-11 13:28   ` Wolfgang Denk
2009-01-11 14:35     ` Frans Meulenbroeks
2009-01-11 21:56       ` Wolfgang Denk
2009-01-11 20:30     ` Schlaegl Manfred jun.
     [not found] <mailman.2543.1231435349.2783.u-boot@lists.denx.de>
2009-01-08 18:27 ` Derek Ou
     [not found] <mailman.2551.1231706115.2783.u-boot@lists.denx.de>
2009-01-13 14:55 ` David.Kondrad at onqlegrand.com

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=127097.50795.qm@web33604.mail.mud.yahoo.com \
    --to=fransmeulenbroeks@yahoo.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