Re: [Yaffs] cvs YAFFS + MTD cvs + 2.4.27-vrs1 problems

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: tglx
CC: Nick Bane, Aras Vaichas, YAFFS
Subject: Re: [Yaffs] cvs YAFFS + MTD cvs + 2.4.27-vrs1 problems
On Friday 10 December 2004 21:47, Thomas Gleixner wrote:
> On Fri, 2004-12-10 at 13:32 +1300, Charles Manning wrote:
> > I might argue the latter point here. I believe the ECC byte ordering
> > calculated by SJHill's nand_ecc.c is wrong. yaffs_ecc.c can calculate
> > this ECC order or the SmartMedia "correct" order. yaffs_ecc.c is also
> > slightly faster than nand_ecc.c ;-).
>
> I have no problem to put a faster algorithm into nand_ecc.c. The byte
> ordering is simple to fix by
>
> -        eccpos: {8, 9, 10, 13, 14, 15}
> +        eccpos: {9, 8, 10, 14, 13, 15}

>
> or whatever byte ordering is the correct one.
>
> > I don't think I have a gripe with the ECC stuff, it's the write
> > verification that gets me.
>
> Why ? The nand driver provides write verify and tells you when it
> failed.


When I write the deletion markers or bad block marking I don't want to use
verification.

When you program NAND, writing 0xFF does not mean "set this to 0xFF" it means
"don't do anything to these bytes". The verifying does not work this way.
Perhaps it would be nice to have a flag to apply or ignore verification.

>
> > From my understanding this is only a configuration issue.
> >
> > YAFFS can be build with CONFIG_YAFFS_USE_NAND_ECC which means yaffs won't
> > do ECC - it lets mtd do all ECC. This is, IMHO, the best way to do things
> > with Linux - particularly if there are other non-yaffs users of the NAND.
> >
> > With non-Linux usage, I recommend using yaffs_ecc.c if software ECC is
> > required.
>
> Sure, but I strongly recommend to seperate this from the filesystem.


In YAFFS2 it is so :-).

>
> > Where things do break down a bit is with mkyaffs which does calculate
> > ECC. You need to be careful to use a consistent ECC strategy.
>
> Yep, but I notice that most newer designs use hardware ecc, which
> sometimes leads to strange page layouts and uses other algorithms e.g.
> Reed-Solomon, so the generic mkyaffs - generate everything - will not
> work anymore.
>
> As we discussed before the only way to solve this is ECC autoplacement,
> which is unfortunately not possible with YAFFS1 although it could be
> tweaked to use it. YAFFS2 uses autoplacement ?


It would be quite simple to modify YAFFS1 to work with autoplacement. YAFFS2
uses autoplacement.

>
> To provide images which can be programmed into the FLASH during
> manufacturing you will need a different approach.
>
> - mkyaffs provides the filesystem data
>
> - an ecc generator which must be aware of the algortihm and the
> placement builds the final image which can be programmed to the chip
>
> - If you can programm it from the OS, then you can read the image back
> from the chip and you do not need a software emulation of the ecc and
> placement
>
> tglx
>
>
>
> _______________________________________________
> yaffs mailing list
>
> http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs