On Friday 10 December 2004 11:55, Thomas Gleixner wrote:
> On Thu, 2004-12-09 at 21:10 +0000, Nick Bane wrote:
> > That is precisely what I do and I comment out the MTD whinge.
> > It is clearly important that SOMEONE does the ECC and it is a
> > mild pity that the MTD layer assumes that only it is competant to do so.
>
> It's not a pity. It's correct. If you do software ECC, fine. If you have
> hardware ECC then it _CAN_ only be done in the MTD layer. The filesystem
> layer does not know anything about the available hardware. So it makes
> totaly sense that ECC is done in the MTD/NAND layer and nowhere else.
>
> A filesystem is a filesystem and is not competent to fiddle around with
> hardware. I know that there are OS targets for YAFFS where YAFFS has to
> do everything, but MTD does it the right way.
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 don't think I have a gripe with the ECC stuff, it's the write verification
that gets me.
>
> > It is probably that yaffs should get the MTD layer to do its ecc
> > eventually as standard.
>
> Can you please explain this statement to somebody who's native language
> is German ?
>
> What do you mean ?
> Fix YAFFS or hack MTD ?
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.
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.
(text/plain)