Charles,
I was sidetracked for a few weeks on other tasks, but am back to
working on this now. I'm able to reliably dump and read back in yaffs2
images to/from a nandsim emulated mtd device under Linux. I also have a
binary that appears to correctly dump the yaffs2 filesystem from an
Android device, including the oob area. The output is the right length,
anyway, and structurally, the first few pages look similar to what is
working on the Linux side. However I'm still unable to get the dumped
Android yaffs2 image to load under Linux in such a way as to mount and
be accessible. Whenever I mount the resultant filesystem, it only
appears to have an empty lost+found directory, nothing else.
I just came up with a possible explanation. Doesn't Android use
big-endian byte ordering? If that's the case, then maybe the image needs
to be converted to little-endian format in order to mount properly under
Linux? Does this sound possible, or have I just wandered completely off
the map? If this is my problem, does anybody know where I might find a
utility to do the conversion?
Thanks much
John
-----Original Message-----
From: Charles Manning [
mailto:manningc2@actrix.gen.nz]
Sent: Monday, December 07, 2009 3:55 PM
To:
yaffs@lists.aleph1.co.uk
Cc: McCash John-GKJN37; Andrew Hoog
Subject: Re: [Yaffs] Access to files on a YAFFS2 image
On Tuesday 08 December 2009 02:27:46 McCash John-GKJN37 wrote:
> 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.
Sounds like the right conclusion.
>
> 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?
>From a quick scan of the code I would expect that mtd_read_raw also
reads oob
while mtd_read_data does not.
> Thanks
> John
>
> -----Original Message-----
> From: Charles Manning [mailto:manningc2@actrix.gen.nz]
> 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
> 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
>
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
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
(text/plain)