From patchwork Thu May 19 05:32:17 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Matthew L. Creech" X-Patchwork-Id: 96312 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 28F5C1007D7 for ; Thu, 19 May 2011 15:33:56 +1000 (EST) Received: from canuck.infradead.org ([134.117.69.58]) by bombadil.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QMvqX-000516-Il; Thu, 19 May 2011 05:32:29 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QMvqW-0000y3-RX; Thu, 19 May 2011 05:32:28 +0000 Received: from mail-vx0-f177.google.com ([209.85.220.177]) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QMvqT-0000xj-IS for linux-mtd@lists.infradead.org; Thu, 19 May 2011 05:32:26 +0000 Received: by vxd2 with SMTP id 2so2094864vxd.36 for ; Wed, 18 May 2011 22:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:date:message-id:x-mailer :in-reply-to:references; bh=/TvRCVyGBHQf/I8qJs3/jURMNxOx1uTStVTnBqJlngc=; b=Xb33XUa/QGHMBw+pNB8d2ItNNkRKkwmz28bL3L9rh9/0e3PW9LY958nwTEA4l2oO8/ TlQKQOd4mIM+1vLdxsF3ht0nc6nNNxlpoegCIK0/cp6gkXLmbpdX1PATJ+sSeekxUvm/ oCxt0dy/Xnj+DDKIf6lI2FKF1Q0Ubv0fINyss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; b=VxJmyB5riRDXgUZYPAU30BKKXwTL3ytChxpnZh//l0lHuMDk2zJ6R1nyA1V7Fufo6z PJAlIO+1aGdpIJLZqq7W15Rb4NylG5gcNXJ14QOnzxCazg5uCCuk+RWiYur/LehjHarV bDhVYFD8PPAAIr5usNq7aRhHHiJUBdLouYqTo= Received: by 10.220.102.131 with SMTP id g3mr825386vco.121.1305783144201; Wed, 18 May 2011 22:32:24 -0700 (PDT) Received: from localhost.localdomain (cpe-076-182-084-041.nc.res.rr.com [76.182.84.41]) by mx.google.com with ESMTPS id d1sm508906vch.38.2011.05.18.22.32.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 22:32:23 -0700 (PDT) From: "Matthew L. Creech" To: linux-mtd@lists.infradead.org Subject: [PATCH] UBIFS: document the "free space fixup" flag Date: Thu, 19 May 2011 01:32:17 -0400 Message-Id: <1305783137-13374-1-git-send-email-mlcreech@gmail.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1305197870.2713.95.camel@localhost> References: <1305197870.2713.95.camel@localhost> X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110519_013225_754164_BC67799C X-CRM114-Status: GOOD ( 18.15 ) X-Spam-Score: -0.8 (/) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (-0.8 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is freemail (mlcreech[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.220.177 listed in list.dnswl.org] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 RFC_ABUSE_POST Both abuse and postmaster missing on sender domain 0.0 T_TO_NO_BRKTS_FREEMAIL T_TO_NO_BRKTS_FREEMAIL Cc: dedekind1@gmail.com X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org 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?