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
>