From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from allen.werkleitz.de ([80.190.251.108]) by pentafluge.infradead.org with esmtps (Exim 4.54 #1 (Red Hat Linux)) id 1EmYhY-0006Mj-Fr for linux-mtd@lists.infradead.org; Wed, 14 Dec 2005 15:37:57 +0000 Received: from p54bea901.dip0.t-ipconnect.de ([84.190.169.1] helo=void.local) by allen.werkleitz.de with esmtpsa (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1EmYhJ-0004RR-Op for linux-mtd@lists.infradead.org; Wed, 14 Dec 2005 16:37:47 +0100 Received: from js by void.local with local (Exim 3.35 #1 (Debian)) id 1EmYhI-0002nL-00 for ; Wed, 14 Dec 2005 16:37:40 +0100 Date: Wed, 14 Dec 2005 16:37:40 +0100 From: Johannes Stezenbach To: linux-mtd@lists.infradead.org Message-ID: <20051214153740.GB10310@linuxtv.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: padding in mkfs.jffs2 and nandwrite List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi, I've prepared a jffs2 image with mkfs.jffs2 and written it to NAND flash using nandwrite (details below). When the file system is mounted r/w and written to, on future mounts the following warning appears: Empty flash at 0x000000f8 ends at 0x00000200 This is caused by the padding added by either mkfs.jffs2 -p512 or nandwrite -p, because this padding is 0xff, which jffs2 sees as "free space which was wasted" (when jffs2 flushes a page to disk it pads with 0x00, so it can tell that this space was deliberately left unused). (I think this warning will evetually go away when the block is garbage collected, but this can take a loooong time.) To avoid this warning I would like to suggest that we either change mkfs.jffs2 and nandwrite to pad with 0x00, or add an option to both to choose the padding value. One additional question: Why does mkfs.jffs2 -p by default pad to the end of the erase block? When whole pages are written with all 0xff, but the first N pages of an erase block contain valid nodes, jffs2 will assume that these pages are freshly erased and good to write in. Won't this cause instable bits when written again by jffs2? (The data sheet for my flash says that there may be up to three partial page write before erase is needed, but I'm not sure if this allows to write the same byte twice.) What I currently do to avoid the issue: $ mkfs.jffs2 -v -e16384 -d foo -b -n -q | dd bs=512 conv=sync >foo.jffs2 $ flash_eraseall -j /dev/mtd0 $ nandwrite /dev/mtd0 foo.jffs2 Johannes