UBI - exclude bootloader blocks from wear levelling

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?

Thanks for your help,
Lauren.
----
This message contains confidential information and may contain information that is legally privileged. If you have received this message by mistake, please immediately notify us and delete the original message. Thank you.

Ce message contient des informations confidentielles. S'il vous est parvenu par erreur, merci de bien vouloir nous en aviser par retour, de n'en faire aucun usage et de n'en garder aucune copie.
----

Wear levelling is done across a "ubi device" (not the whole nand device) which is associated with a mtd partition. Your bootloader and kernel mtd partitions will not be wear levelled, only your ubi file system partitions. i.e. ubi doesn't know about non-ubi mtd partitions.

I think that's the gist of it.

Darwin

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Lauren Del Giudice
Sent: Monday, December 21, 2009 8:46 AM
To: [email protected]
Subject: UBI - exclude bootloader blocks from wear levelling

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?

Thanks for your help,
Lauren.
----
This message contains confidential information and may contain information that is legally privileged. If you have received this message by mistake, please immediately notify us and delete the original message. Thank you.

Ce message contient des informations confidentielles. S'il vous est parvenu par erreur, merci de bien vouloir nous en aviser par retour, de n'en faire aucun usage et de n'en garder aucune copie.
----

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

That's my understanding also.

Could you maybe clarify another point? If I wanted to exclude some blocks that contain boot code (like Lauren's question), and the leftover space on the NAND device was ultimately going to be used for four different volumes, does it make the most sense to...

a) define one MTD partition that includes all NAND space (except the blocks reserved for boot code); and then define one UBI device that attaches to the MTD device and includes the four volumes (ubi0_0, ubi0_1, ubi0_2, ubi0_3)

OR

b) define four MTD partitions that include all NAND space (except the blocks reserved for boot code); and then define four UBI devices that attach to the MTD devices and each UBI device has one volume associated with it (ubi0_0, ubi1_0, ubi2_0, ubi3_0)?

Thanks,
twebb

My understanding is that wear levelling occurs across each ubi device, and if there were 4 volumes on it, then the wear levelling would be spread efficiently over the single large device. Then you probably get better wear levelling than if you had 4 smaller devices and 4 volumes.

I'm guessing that statistically it is better to wear level across as large a device as possible, since the wearing would be shared among many more blocks and all logical volumes reap the benefit.

A small device/volume with heavy activity would wear itself out quicker than if it were part of a larger management scheme.

Of course, having separate mtd partitions may make sense for other reasons.

Darwin

-----Original Message-----
From: twebb [mailto:[email protected]]
Sent: Monday, December 21, 2009 2:52 PM
To: Darwin Rambo
Cc: Lauren Del Giudice; [email protected]
Subject: Re: UBI - exclude bootloader blocks from wear levelling

That's my understanding also.

Could you maybe clarify another point? If I wanted to exclude some blocks that contain boot code (like Lauren's question), and the leftover space on the NAND device was ultimately going to be used for four different volumes, does it make the most sense to...

a) define one MTD partition that includes all NAND space (except the blocks reserved for boot code); and then define one UBI device that attaches to the MTD device and includes the four volumes (ubi0_0, ubi0_1, ubi0_2, ubi0_3)

OR

b) define four MTD partitions that include all NAND space (except the blocks reserved for boot code); and then define four UBI devices that attach to the MTD devices and each UBI device has one volume associated with it (ubi0_0, ubi1_0, ubi2_0, ubi3_0)?

Thanks,
twebb

Right.

WL works on UBI device, which corresponds to the attached MTD device. So there is 1-1 mapping between MTD and UBI devices. And each UBI device may contain many volumes.

Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Good news, thank you Darwin. May I suggest then to change the sentence in the (excellent) documentation from:

"you may continuously write/erase only one logical eraseblock of an UBI volume, but UBI will spread this to all physical eraseblocks of the flash chip"
<http://www.linux-mtd.infradead.org/doc/ubi.html#L_overview>

to something more explicit/accurate?

Lauren.

----
This message contains confidential information and may contain information that is legally privileged. If you have received this message by mistake, please immediately notify us and delete the original message. Thank you.

Ce message contient des informations confidentielles. S'il vous est parvenu par erreur, merci de bien vouloir nous en aviser par retour, de n'en faire aucun usage et de n'en garder aucune copie.
----

Artem is on holidays, I'm sure he'll get around to it when he returns. Good suggestion.

Darwin

-----Original Message-----
From: Lauren Del Giudice [mailto:[email protected]]
Sent: Tuesday, December 22, 2009 12:08 AM
To: Darwin Rambo
Cc: [email protected]
Subject: Re: UBI - exclude bootloader blocks from wear levelling

Good news, thank you Darwin. May I suggest then to change the sentence in the (excellent) documentation from:

"you may continuously write/erase only one logical eraseblock of an UBI volume, but UBI will spread this to all physical eraseblocks of the flash chip"
<http://www.linux-mtd.infradead.org/doc/ubi.html#L_overview>

to something more explicit/accurate?

Lauren.

----
This message contains confidential information and may contain information that is legally privileged. If you have received this message by mistake, please immediately notify us and delete the original message. Thank you.

Ce message contient des informations confidentielles. S'il vous est parvenu par erreur, merci de bien vouloir nous en aviser par retour, de n'en faire aucun usage et de n'en garder aucune copie.
----

Dear Lauren Del Giudice,

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

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: [email protected]
Even if you aren't in doubt, consider the mental welfare of the  per-
son who has to maintain the code after you, and who will probably put
parens in the wrong place.          - Larry Wall in the perl man page

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: [email protected] [mailto:[email protected]] On Behalf Of Wolfgang Denk
Sent: Tuesday, December 22, 2009 10:33 PM
To: Lauren Del Giudice
Cc: [email protected]
Subject: Re: UBI - exclude bootloader blocks from wear levelling

Dear Lauren Del Giudice,

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

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: [email protected]
Even if you aren't in doubt, consider the mental welfare of the  per-
son who has to maintain the code after you, and who will probably put
parens in the wrong place.          - Larry Wall in the perl man page

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

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.

Dear "Darwin Rambo",

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

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.

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

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: [email protected]
Defaults are wonderful, just like fire.
                  - Larry Wall in <[email protected]>

The bootstrap for portable devices might boot up just thousands of time in product lifetime, and with strong ECC this seems like a reasonable compromise of simplicity vs complexity. Also my simple bootstrap fits within a single block, so wear levelling in my case doesn't make much sense. The strong ECC seems more suitable for this type of situation. Of course, larger u-boot based bootstraps are better candidates for the wear levelling / UBI approach as you suggest.

Thanks for the excellent link.

Darwin

So you basically want:

1. reserve the first N PEBs for the boot-loader, kernel, whatever. You do not want UBI to touch these N ones.
2. The rest M PEBs you want to feed UBI.

(PEB = physical erase-block)

UBI works on top of MTD devices, or MTD partitions. So all you need is to properly partition your NAND. Make sure your MTD partition which you feed to UBI covers only those M PEBs.

E.g., you may have /dev/mtd0 which is "mapped" to the 1st N PEBs, and /dev/mtd1 which is mapped to the rest. And then you attach /dev/mtd1 to UBI. UBI will touch only /dev/mtd1. People do this.

Simply speaking, UBI works on top of the MTD device you gave it. You are free to partition your NAND chip as you wish.

P.S.: you may even have 2 NAND chips, create a striping layer on top of them, expose them as one single "striped" MTD device, and feed that one to UBI.

HTH.

But yes, you should take into account the points Wolfgang provided.

Best Regards,
Artem Bityutskiy (Артём Битюцкий)