The best way to look at mkyaffsimage, IMHO, is as a hackable tool that
you reconfigure to your needs. mkyaffsimage is pretty straight forward,
so this is easily done.
mkyaffsimage was written quite a while back and has not been made
flexible to work with different OOB layouts. All that is needed is to
mess around with write_chunk which is a very short and, IMHO, easy to
understand function.
If someone wants to make mkyaffsimage more flexible and contribute it
back(eg. James Ng contributed a pitch for BE and LE), that would be fine
too.
> I understand what's been said but I'm unclear on how the
> tools (mkyaffsimage, mkyaffs, and nandwrite) can be used in
> conjunction with this mechanism. Please point out the flaw in
> the following
> analysis:
>
> It seems like mkyaffsimage generates an image
> that contains the OOB info based on how it wants the tags placed:
>
> typedef struct
> {
> __u8 tagByte0;
> __u8 tagByte1;
> __u8 tagByte2;
> __u8 tagByte3;
> __u8 pageStatus; // set to 0 to delete the chunk
> __u8 blockStatus;
> __u8 tagByte4;
> __u8 tagByte5;
> __u8 ecc1[3];
> __u8 tagByte6;
> __u8 tagByte7;
> __u8 ecc2[3];
> } yaffs_Spare;
>
>
> Both nandwrite and mkyaffs will then use the MEMWRITEOOB
> ioctl to write these 16 bytes to the OOB. MEMWRITEOOB doesn't
> appear to use the oobfree info to figure out how to write the
> OOB info so it looks to me like it
> will write these 16 bytes as layed out above (which will not
> work with the hardware ecc placement scheme I am using).
>
> Is this just a case where the tools should really be using
> GETOOBSEL to figure out where the free bytes are and then
> program accordingly?
>
> >
> >tglx
> >
> >
> >
> >
> >
>
> _______________________________________________
> yaffs mailing list
> yaffs@stoneboat.aleph1.co.uk
> http://stoneboat.aleph1.co.uk/cgi-> bin/mailman/listinfo/yaffs
>
(text/plain)