All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: "Darwin Rambo" <drambo@broadcom.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Lauren Del Giudice <lauren@wyplay.com>
Subject: Re: UBI - exclude bootloader blocks from wear levelling
Date: Wed, 23 Dec 2009 22:40:01 +0100	[thread overview]
Message-ID: <20091223214001.815CD3F6EF@gemini.denx.de> (raw)
In-Reply-To: <B125D8217ABC4B43826503DE00A2D44910DFC17927@SJEXCHCCR01.corp.ad.broadcom.com>

Dear "Darwin Rambo",

please do not top-post / full qoute. See
http://www.netmeister.org/news/learn2quote.html


In message <B125D8217ABC4B43826503DE00A2D44910DFC17927@SJEXCHCCR01.corp.ad.broadcom.com> you wrote:
> I think Lauren must have been referring to a bootloader that lives
> outside the kernel and file system context. For example, a small,
> standalone bootloader downloaded from a serial port to it's own
> partition, would not be known to the kernel, as it is used to launch
> the kernel or later stage bootloaders. In this case it runs
> standalone and can't sit on UBI or be launched by a linux app. If

Of course it can, assuming it is UBI-aware by itself. For example,
U-Boot is such a boot loader that can load the U-Boot image itself
from a UBI partition in NAND.

> this small bootloader was only a block or two in size, and since it
> is typically burned once for production and then becomes read-only
> for each bootup after that, wear levelling is not required or
> possible.

Noite that "read-only" is not sufficient. NAND flash will develop
errors even if you just read it often enough. See for example this
Micron Application Note:
http://download.micron.com/pdf/technotes/nand/tn2917.pdf

> Flash data retention periods are usually specified in years, and

I am not talking about "data retention" here. See section "NAND Flash
is Not a Hard Drive" in the above Application Note to understand what
I mean.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Defaults are wonderful, just like fire.
                  - Larry Wall in <1996Mar6.004121.27890@netlabs.com>

  parent reply	other threads:[~2009-12-23 21:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-21 16:46 UBI - exclude bootloader blocks from wear levelling Lauren Del Giudice
2009-12-21 21:30 ` Darwin Rambo
2009-12-21 22:51   ` twebb
2009-12-21 23:12     ` Darwin Rambo
2010-01-09 23:18       ` Artem Bityutskiy
2009-12-22  8:08   ` Lauren Del Giudice
2009-12-22 14:03     ` Darwin Rambo
2009-12-23  6:32 ` Wolfgang Denk
2009-12-23 17:12   ` Darwin Rambo
2009-12-23 21:08     ` Lauren Del Giudice
2009-12-23 21:40     ` Wolfgang Denk [this message]
2009-12-23 23:39       ` Darwin Rambo
2010-01-09 23:14 ` Artem Bityutskiy

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=20091223214001.815CD3F6EF@gemini.denx.de \
    --to=wd@denx.de \
    --cc=drambo@broadcom.com \
    --cc=lauren@wyplay.com \
    --cc=linux-mtd@lists.infradead.org \
    /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.