On Tuesday 28 June 2011 14:13:39 Peter Pilley wrote:
> Charles
>
> I am really doing my head in with a nanddump img trying to use the same
> rules I have developed for mkyaffs2image for this.
>
> I am seeing the OOB area I can see that it is 128 bits (data area of 4096)
That will be 128 bytes.
>
> What I am having trouble with is with mkyaffs2image these objects were easy
> to identify and mark with nanddump they are not I am geussing cause they
> are deleted and live data.
That is part of it. The other is that mkyaffs2image only writes the minimum of
chunk types:
* data chunks
* object headers (simple layout only)
mkyaffs2image does not write any of:
* packed tags.
* block summary data
* checksum data
>
> with one chunk of data I am seeing is the oob data with mkyaffs2image is
> the entire 64bytes
It isn't really. It is still only around 28 bytes of actual tags info + ECC
and other stuff.
> whereas the oob data with nanddump is only 29 bytes of
> the 128 bytes.
>
> Also the data doesnt make sense with some having chunk sizes significantly
> larger than available ie 4096 is max but chunk sizes of 406800 and in some
> cases the object id is in the wrong location.
The mtd provides (to yaffs) the ability to read/write a sequence of bytes to
be stored in the oob. The oob will also be used to save ECC and bad block
markers etc.
The location of those bytes in the oob area is determined by the flash driver
and not by yaffs.
>
> eg.
>
> 34 1F 01 00 DA 02 00 10 D0 02 00 80 00 08 07 00
> 00 00 00 00 00 00 00 00 01 00 00 00
>
> the object should be 72 or 2D0 but 2DA is presented in its place. the chunk
> size is 00880088 = 134250496 bytes or if you read it as 000807 its the
> filesize., this is a header not a data chunk and should have a chunk size
> of 0xFFFF.
There is a further wrinkle. yaffs2 writes tags using what care called "packed
tags". This stores extra information in the tags area. Since an object header
has no need for an nbytes or chunkId field, yaffs packs in other info which
speeds the scanning,
Look up packed tags in HowYaffsWorks.pdf. Code in yaffs_packedtags2.h and .c.
>
> here is the same header chunk with mkyaffs2image I understand the blockID
> and object ID are different but the chunkID and Chunk size should be the
> same shouldnt they
>
> 00 10 00 00 10 07 00 00 00 00 00 00 FF FF 00 00
> 1A FF FF FF 00 00 00 00 FF FF FF FF FF FF FF FF
> 00 00 00 00 68 E3 D1 BE 01 00 00 00 50 CF D1 BE
> 10 07 00 00 18 0B 08 00 D4 87 00 00 01 00 00 00
packed tags are the difference.
>
> Sorry to dump this on you but this is the only thing I cannot explain for
> my dissertation
It looks like you are almost there.
I suggest that if you run yaffs2 in the test harness with a debugger (doing
both writing and scanning) it will be easier to understand what is happening.
>
> On Tue, Jun 28, 2011 at 10:57 AM, Peter Pilley
<
peter.pilley@gmail.com>wrote:
> > Sorry I just assumed it was oob due it talking about yaffs_objects, my
> > fault
> >
> > On Tue, Jun 28, 2011 at 10:36 AM, Charles Manning
> > <manningc2@actrix.gen.nz
> >
> > > wrote:
> >>
> >> On Monday 27 June 2011 15:32:52 Peter Pilley wrote:
> >> > Everyone on List
> >> >
> >> > What are the differences between
> >> >
> >> > __u8 deleted: 1; // This should only apply to unlinked
> >>
> >> files.
> >>
> >> > __u8 softDeleted: 1; // it has also been soft deleted
> >>
> >> This is described in HowYaffsWorks.pdf.
> >> Soft deletion is only used in yaffs1 mode.
> >>
> >> > These have been described in yaffs_guts.h
> >> >
> >> >
> >> > would there values only possibly be 0x01 or 0x00?
> >>
> >> Yes, that is what C bitfields mean.
> >> http://en.wikipedia.org/wiki/Bit_field
> >>
> >> > yaffs_guts suggests they appear in the oob area but I cannot see
> >> > anything like this however I am still trying to identify what flags
> >> > say it is a live file or data_chunk
> >>
> >> They are not in the oob area. What makes you say that this is suggested?
> >>
> >> -- Charles
(text/plain)