From: Lauren Del Giudice <lauren@wyplay.com>
To: Darwin Rambo <drambo@broadcom.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: UBI - exclude bootloader blocks from wear levelling
Date: Wed, 23 Dec 2009 22:08:12 +0100 [thread overview]
Message-ID: <4B3286BC.2070704@wyplay.com> (raw)
In-Reply-To: <B125D8217ABC4B43826503DE00A2D44910DFC17927@SJEXCHCCR01.corp.ad.broadcom.com>
Yes, this is my use case. So I would be in trouble if bootloader (a
first stage loader) does no longer reside at 0.
Thanks, anyway.
Lauren.
Darwin Rambo 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 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.
>
> Flash data retention periods are usually specified in years, and flash write/erases are in cycles. MLC and SLC flashes typically mention 10 year lifetimes in their data sheets, and the program/erase cycles are typically 100K-1M for SLC, and 10K-100K for MLC. As such I don't see an issue wrt boot loader integrity on factory burning or years of subsequent bootups.
>
> Hope this helps a bit.
>
> Darwin
>
> -----Original Message-----
> From: linux-mtd-bounces@lists.infradead.org [mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of Wolfgang Denk
> Sent: Tuesday, December 22, 2009 10:33 PM
> To: Lauren Del Giudice
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: UBI - exclude bootloader blocks from wear levelling
>
> Dear Lauren Del Giudice,
>
> In message <4B2FA658.6010407@wyplay.com> you wrote:
>> I'm new to UBI... I understood that static wear levelling is applied
>> accross the whole device (a NAND device in my case); If so, how can
>> I exclude blocks reserved for the bootloader from wear levelling?
>
> Why would you want to do that? You should be happy that UBI also
> applies wear levelling to the bootloader storage, as this prevents
> your device from bricking when read errors develop there. Keep in mind
> that NAND blocks will develop read errors even if you only read them
> (i. e. there is not only a limit on the number of erase cycles of such
> a device, but also on the number of read cycles).
>
> It is a great benefit if your boot loader gets loaded from a UBI
> partition instead of raw NAND.
>
> Best regards,
>
> Wolfgang Denk
>
next prev parent reply other threads:[~2009-12-23 21:12 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 [this message]
2009-12-23 21:40 ` Wolfgang Denk
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=4B3286BC.2070704@wyplay.com \
--to=lauren@wyplay.com \
--cc=drambo@broadcom.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox