From john.mccash@motorola.com Mon Dec 07 13:28:37 2009 Received: from mail119.messagelabs.com ([216.82.241.195]) by stoneboat.aleph1.co.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NHddf-0001Ir-Nq for yaffs@lists.aleph1.co.uk; Mon, 07 Dec 2009 13:28:37 +0000 X-VirusChecked: Checked X-Env-Sender: john.mccash@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1260192498!33998595!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17359 invoked from network); 7 Dec 2009 13:28:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Dec 2009 13:28:19 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id nB7DS8Vk009142 for ; Mon, 7 Dec 2009 06:28:18 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id nB7DS8DA023255 for ; Mon, 7 Dec 2009 07:28:08 -0600 (CST) Received: from de01exm71.ds.mot.com (de01exm71.am.mot.com [10.176.8.27]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id nB7DS8Ju023249 for ; Mon, 7 Dec 2009 07:28:08 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Dec 2009 08:27:46 -0500 Message-ID: In-Reply-To: <200912070918.13634.manningc2@actrix.gen.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Yaffs] Access to files on a YAFFS2 image thread-index: Acp2sVFflgrPWAXDS/63a9FNQ/9IpwAjhsEQ References: <200912021026.08366.manningc2@actrix.gen.nz> <200912070918.13634.manningc2@actrix.gen.nz> From: "McCash John-GKJN37" To: "Charles Manning" , X-CFilter-Loop: Reflected X-SA-Exim-Connect-IP: 216.82.241.195 X-SA-Exim-Mail-From: john.mccash@motorola.com X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on stoneboat.aleph1.co.uk X-Spam-Level: X-Spam-Status: No, score=-6.6 required=4.5 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk) Cc: Andrew Hoog Subject: Re: [Yaffs] Access to files on a YAFFS2 image X-BeenThere: yaffs@lists.aleph1.co.uk X-Mailman-Version: 2.1.11 Precedence: list List-Id: Discussion of YAFFS NAND flash filesystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 13:28:38 -0000 Charles, Yes. I understood that, or so I thought. When dumping with nanddump under Linux and not including the -o flag, the output is larger than the size listed in /proc/mtd, and can be uploaded to another mtd device with nandwrite -o. When dumped with the -o flag, the size the same as that specified in /proc/mtd, and the resultant file cannot be written with nandwrite -o. When I dump from a partition of the same size (as shown in /proc/mtd) on an android phone, using the dump_image-arm utility I got from the nandroid package, the result is the same size as the partition size value from /proc/mtd. My conclusion was that dump_image-arm is not including the oob area in its output. I looked at the source for dump_image briefly, but I find no mention of either "oob" or "out of bounds" anywhere. Where am I going off in the weeds? Thanks John -----Original Message----- From: Charles Manning [mailto:manningc2@actrix.gen.nz]=20 Sent: Sunday, December 06, 2009 2:18 PM To: yaffs@lists.aleph1.co.uk Cc: McCash John-GKJN37; Andrew Hoog Subject: Re: [Yaffs] Access to files on a YAFFS2 image The -o flag is tricky because the meaning is reversed between nanddump and=20 nandwrite: Usage: nanddump [OPTIONS] MTD-device ... -o --omitoob omit oob data .... Usage: nandwrite [OPTION] MTD_DEVICE INPUTFILE ... -o, --oob image contains oob data ... The dump_image tool contains oob Look at=20 http://svn.infernix.net/nandroid/nandtools/android-imagetools/dump_image .c to see what you're getting from dump_image. -- Charles On Saturday 05 December 2009 10:54:44 McCash John-GKJN37 wrote: > Charles, > For what it's worth, I think I've figured out what's wrong. The > size returned in /proc/mtd does not include the oob area. I verified > this by creating an mtd device the same size as the one I'm trying to > examine an image of, and then dumping it with nanddump. The resultant > image is larger than the size of the device. I can also copy this image > back in with nandwrite. However if I dump it with the -o option, to > exclude oob, the image dumped is exactly the size listed in /proc/mtd. > > Now I just have to find somewhere a precompiled copy of nanddump > for ARM. (I have a deep and abiding fear of cross-compilers.) I don't > suppose anyone on the list could direct me to such an animal? > > Thanks > John > > -----Original Message----- > From: Charles Manning [mailto:manningc2@actrix.gen.nz] > Sent: Tuesday, December 01, 2009 3:26 PM > To: yaffs@lists.aleph1.co.uk > Cc: McCash John-GKJN37; Andrew Hoog > Subject: Re: [Yaffs] Access to files on a YAFFS2 image > > What I suggest is that you first start off by running yaffs on the > nandsim > then doing a dump from that and checking that looks like it should and > that > you can then nandwrite that back. > > Once you can make the process work with just one device it is then a lot > > easier to see why things don't work when importing from somewhere else. > > -- Charles > > On Wednesday 02 December 2009 01:57:04 McCash John-GKJN37 wrote: > > Charles, > > OK, so we apparently do have the OOB data in these image dumps > > (obtained via the dump_image-arm tool included in nandroid), but when > > we > > > attempt to upload them to a nand emulator (under Ubuntu) with > > 'nandwrite > > > -a -o', we're still getting the error: > > > > Input file is not page-aligned. Use the padding option. > > Data was only partially written due to error > > > > : Success > > > > Where do we go from here? Should this work, and if so, how do we > > determine exactly what the problem really is? > > > > Thanks much for your help > > John McCash > > > > _______________________________________________ > > yaffs mailing list > > yaffs@lists.aleph1.co.uk > > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > _______________________________________________ > yaffs mailing list > yaffs@lists.aleph1.co.uk > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs