Author: David Goodenough Date: To: yaffs Subject: Re: [Yaffs] Problem with Yaffs on Routerboard RB112 and kernel
2.6.19
On Thursday 10 May 2007, David Goodenough wrote: > On Thursday 10 May 2007, David Goodenough wrote:
> > On Wednesday 09 May 2007, Charles Manning wrote:
> > > If you're getting ECC errors here it is possibly because the flash has
> > > been written using yaffs_ecc.c and read (with nand_dump) using mtd's
> > > nand_ecc.c
> > >
> > > nand_ecc.c generates exaclty the same data as yaffs_ecc.c, but the byte
> > > ordering is different. Both implement the SmartMedia ECC mechanism, but
> > > the byte order is broken in nand_ecc.c
> >
> > Reading this I thought that I would look at the config options for MTD.
> > And sure enough there is one (that was not set) called
> > CONFIG_MTD_NAND_ECC_SMC which was not set. So I tried setting it, but it
> > does not seem to make any difference - I get the same problems.
>
> Actually, looking at the code there is a typo in nand_ecc.c. It uses
> CONFIG_NAND_ECC_SMC not CONFIG_MTD_NAND_ECC_SMC. This is fixed in 2.6.20
> but not in 2.6.19. So I have put my own patch in to fix that, and I am
> rebuilding my kernel as I type. But I have to pop out for an hour or so
> so I will report when I return. OK, that did not fix the problem. So it looks as though we need to work
with what Ian McDonnell suggested in another part of this thread. Being
new to Yaffs and MTD I do not feel qualified to suggest how to implement
what he suggests, but I am ready to test anything that might be suggested.
David >
> David
>
> > When I mount the partition, all the blocks are flaged as bad and when I
> > use nanddump it complains about uncorrectable bitflips just as before.
> >
> > What change is needed to nand_ecc.c to get the byte order the same as
> > yaffs_ecc.c. A brief look had them looking very similar, but of course I
> > may have missed something.
> >
> > David
> >
> > > There are two solutions to this mess:
> > > 1) Microtik should provide their driver configs under GPL.
> > > 2) Trace through the data reading/writing to see where the OOB byte
> > > ordering is getting screwed up.
> >