From patchwork Thu May 19 05:32:17 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: UBIFS: document the "free space fixup" flag From: "Matthew L. Creech" X-Patchwork-Id: 96312 Message-Id: <1305783137-13374-1-git-send-email-mlcreech@gmail.com> To: linux-mtd@lists.infradead.org Cc: dedekind1@gmail.com Date: Thu, 19 May 2011 01:32:17 -0400 Several parts of the UBI and UBIFS documentation already mention the need to use ubiformat when flashing UBIFS images. Add a new FAQ entry for the "free space fixup" flag as an alternative in recent kernels, and put links to it in these existing locations. --- doc/ubi.xml | 6 ++++++ faq/ubi.xml | 8 +++++--- faq/ubifs.xml | 34 +++++++++++++++++++++++++++++++++- 3 files changed, 44 insertions(+), 4 deletions(-) diff --git a/doc/ubi.xml b/doc/ubi.xml index d22884f..b3ca4ee 100644 --- a/doc/ubi.xml +++ b/doc/ubi.xml @@ -699,6 +699,12 @@ and the writes did not fail. But later we observed weird ECC errors. It took a while to find out the problem. In other words, this is also relevant to JFFS2 images.

+

An alternative to this approach is to enable the "free space fixup" option +when generating the UBIFS file system using mkfs.ubifs. This will +allow your flasher to not have to worry about 0xFF bytes at the end +of PEBs, which is particularly useful if you need to use an industrial flash +programmer to write a UBI image. More information is available +here.

Marking eraseblocks as bad

diff --git a/faq/ubi.xml b/faq/ubi.xml index 8a48a48..f616cfe 100644 --- a/faq/ubi.xml +++ b/faq/ubi.xml @@ -567,9 +567,11 @@ any image, and check if you still have these errors.

related to how you flash the UBI/UBIFS images. One typical problem is related to ECC calculation algorithm - read here for more information. Make sure -that you use ubiformat), or make sure -your flashing program skips 0xFF properly (see -here).

+that you use ubiformat, or make sure +either that your flashing program skips 0xFF properly (see +here) or that your UBIFS image +was generated with the "free space fixup" flag set (see +here).

Another possibility is that your flash reports that it supports sub-pages, but does not actually support diff --git a/faq/ubifs.xml b/faq/ubifs.xml index f1e063c..6e010b5 100644 --- a/faq/ubifs.xml +++ b/faq/ubifs.xml @@ -20,6 +20,7 @@

  • May an empty UBI volume be mounted?
  • What is the purpose of -c (--max-leb-cnt) mkfs.ubifs option?
  • Why do I have to use ubiformat?
    • +
  • What is the the purpose of the -F (--space-fixup) mkfs.ubifs option?
  • How do I compile mkfs.ubifs?
  • What is "favor LZO" compression?
  • Can UBIFS mount loop-back devices?
    • @@ -397,7 +398,9 @@ vol_flags=autoresize (here you may find some hints). Please, read this section for more information -why you should use ubiformat.

    +why you should use ubiformat, or generate your UBIFS images with +the free space fixup flag if that +is not possible.

    @@ -594,6 +597,35 @@ written once and only once after the erasure. If you use nandwrite, some pages are written twice - once by nandwrite, and once by UBIFS.

    +

    If you can not use ubiformat, an alternative is to set the +"free space fixup" flag when generating the UBIFS image (see +here).

    + + +

    What is the the purpose of the -F +(--space-fixup) mkfs.ubifs option?

    + +

    Because of subtle ECC errors that can arise when programming NAND flash +(see here), ubiformat +is the recommended way of flashing a UBI image which contains a UBIFS file +system. However, this is not always possible - for example, some embedded +devices are manufactured using an industrial NAND flash programmer which has +no knowledge of UBI or UBIFS.

    + +

    The -F option causes mkfs.ubifs to set a special +flag in the superblock, which triggers a "free space fixup" procedure in the +kernel the very first time the filesystem is mounted. This fixup procedure +involves finding all empty pages in the UBIFS file system and re-erasing them. +This ensures that NAND pages which contain all 0xFF data get +fully erased, which removes any problematic non-0xFF data from +their OOB areas.

    + +

    This option is supported if you are running a kernel version +2.6.40 or higher. Note that ubiformat is still the +preferred flashing method if the image is not being flashed for the first time, +since it preserves existing erase counters (while using nandwrite +or its equivalent does not).

    +

    How do I compile mkfs.ubifs?