Re: [Yaffs] Scanning yaffs2

On Tuesday 29 March 2011 04:48:47 Serguei Miridonov wrote:
> On Monday 28 March 2011, Ross Younger wrote:
> > * Serguei Miridonov <mirsev@cicese.mx> wrote:
> > > What are the key parameters of mtd device
> > > which are necessary to start the scanning? I know that page size
> > > is 4096 bytes. With hex dump I can see object headers and data
> > > chunks. But I could not find anything like spare areas, so I
> > > don't even know where tags, like objectId, are located.
> >
> > Having the contents of the spare areas is (usually) essential, in
> > order to get the YAFFS tags; without those you don't know the order
> > in which chunks were written and it would be impossible to
> > properly recreate the filesystem.
>
> Is there anything like a manual or simplified description, how the
> kernel driver scans mtd partition? What part of kernel driver should I
> check to get the idea how mtd partition is scanned and where it takes
> the image format?

That is beyond the scope of the yaffs list. Google "linux mtd".

>
> > You need to know the exact format of the mtd dump - what tool has
> > created it?
>
> cat /dev/block/mtdblockN > /sdcard/b-mtdN.img
>
> or
>
> cat /dev/mtd/mtdN > /sdcard/c-mtdN.img
>
> Both commands produce the same files.

Do these dump the oob area too?

I always use nanddump.

>
> > It's just about conceivable that the spare areas for
> > all the chunks are sitting at the end of the file.
>
> Where? Is there any magic string which can be used to find this area?

With nand dump you will end up with the oob areas in stream. A typical
structure would be 2048 bytes of data area followed by 64 bytes of oob.
The tags will most likely be in the oob.
>
> > It's also just about possible that the filesystem was created with
> > the inband_tags mode, in which case you don't need the spare areas
> > and you'll find the tags occupying the last 16 bytes of each
> > chunk's data.
>
> This is `cat /proc/yaffs`
>
> YAFFS built:Nov 14 2010 17:12:19
> $Id$
> $Id$
>
> Device 0 "system"
> startBlock......... 0
> endBlock........... 299
> totalBytesPerChunk. 4096
> nDataBytesPerChunk. 4096
> chunkGroupBits..... 0
> chunkGroupSize..... 1
> nErasedBlocks...... 72
> nReservedBlocks.... 5
> blocksInCheckpoint. 1
> nTnodesCreated..... 2600
> nFreeTnodes........ 61
> nObjectsCreated.... 800
> nFreeObjects....... 94
> nFreeChunks........ 9530
> nPageWrites........ 0
> nPageReads......... 0
> nBlockErasures..... 0
> nGCCopies.......... 0
> garbageCollections. 0
> passiveGCs......... 0
> nRetriedWrites..... 0
> nShortOpCaches..... 10
> nRetireBlocks...... 0
> eccFixed........... 0
> eccUnfixed......... 0
> tagsEccFixed....... 0
> tagsEccUnfixed..... 0
> cacheHits.......... 0
> nDeletedFiles...... 0
> nUnlinkedFiles..... 1
> nBackgroudDeletions 0
> useNANDECC......... 1
> isYaffs2........... 1
> inbandTags......... 0
>
> Device 1 "userdata"
> startBlock......... 0
> endBlock........... 629
> totalBytesPerChunk. 4096
> nDataBytesPerChunk. 4096
> chunkGroupBits..... 0
> chunkGroupSize..... 1
> nErasedBlocks...... 9
> nReservedBlocks.... 5
> blocksInCheckpoint. 1
> nTnodesCreated..... 4800
> nFreeTnodes........ 53
> nObjectsCreated.... 2600
> nFreeObjects....... 98
> nFreeChunks........ 35286
> nPageWrites........ 0
> nPageReads......... 0
> nBlockErasures..... 0
> nGCCopies.......... 0
> garbageCollections. 0
> passiveGCs......... 0
> nRetriedWrites..... 0
> nShortOpCaches..... 10
> nRetireBlocks...... 0
> eccFixed........... 0
> eccUnfixed......... 0
> tagsEccFixed....... 0
> tagsEccUnfixed..... 0
> cacheHits.......... 0
> nDeletedFiles...... 0
> nUnlinkedFiles..... 367
> nBackgroudDeletions 0
> useNANDECC......... 1
> isYaffs2........... 1
> inbandTags......... 0
>
> > unyaffs is probably the best tool for the job, but you'll need to
> > tweak it when you've figured out where the tags are.
>
> Is it at all possible to write a yaffs tool that can read any yaffs2
> image? If not, why?

The issue is that the flash layout depends on the flash driver. Some drivers
place the oob bytes differently. Also, yaffs stores data in a native binary
form.

It would be possible to write one program that decodes an image but that would
need to be parameterised to handle the various layouts.