Well, thanks for everyone for their support.
It turns out that all I had to do is mount the partitions with the -o
inband-tags flag for YAFFS2 to work correctly on my NAND.
On Sun, 2011-01-02 at 19:45 +0200, Boaz Ben-David wrote:
> After doing some reading as proposed in the previous reply I dove back
> into the code and found some new info.
>
> First of all, yaffs is configured in kernel with YAFFS_DISABLE_TAGS_ECC
> because otherwise I was getting some strange behaviour.
>
> I found out the the call to mtd->write_oob(mtd, addr, &ops) in
>
> int nandmtd2_WriteChunkWithTagsToNAND(yaffs_Device *dev, int
> chunkInNAND,
> const __u8 *data,
> const yaffs_ExtendedTags *tags)
>
> Was returning 0 on success and 1 on failure, the opposite from the way
> YAFFS_OK and YAFFS_FAIL are defined. After finding that I switched the
> two and started getting some other errors. From what I saw in the kernel
> log, the verification of the tags (as far as I can see) fails after
> reading back what was written. Here is a part of the log file showing
> the beginning of a cp command:
>
> yaffs_create
> Jan 2 19:29:30 buildroot kernel: yaffs_mknod: parent object 1 type 3
> Jan 2 19:29:30 buildroot kernel: yaffs_mknod: making oject for
> kern.log, mode 8180 dev 0
> Jan 2 19:29:30 buildroot kernel: yaffs locking c7edb200
> Jan 2 19:29:30 buildroot kernel: yaffs locked c7edb200
> Jan 2 19:29:30 buildroot kernel: yaffs_mknod: making file
> Jan 2 19:29:30 buildroot kernel: yaffs: Tnodes added
> Jan 2 19:29:30 buildroot kernel: yaffs_MarkSuperBlockDirty() sb =
> c7f9ce00
> Jan 2 19:29:30 buildroot kernel: Allocated block 1, seq 4097, 11 left
> Jan 2 19:29:30 buildroot kernel: nandmtd2_ReadChunkWithTagsFromNAND
> chunk 0 data c7abf000 tags c7ae3b80
> Jan 2 19:29:30 buildroot kernel: yaffs_UnpackTags2TagsPart
> Jan 2 19:29:30 buildroot kernel: packed tags obj -1 chunk -1 byte -1
> seq -1
> Jan 2 19:29:30 buildroot kernel: ext.tags eccres 0 blkbad 0 chused 0
> obj 0 chunk0 byte 0 del 0 ser 0 seq 0
> Jan 2 19:29:30 buildroot kernel: packed tags obj -1 chunk -1 byte -1
> seq -1
> Jan 2 19:29:30 buildroot kernel: ext.tags eccres 1 blkbad 0 chused 0
> obj 0 chunk0 byte 0 del 0 ser 0 seq 0
> Jan 2 19:29:30 buildroot kernel: nandmtd2_ReadChunkWithTagsFromNAND
> YAFFS_OK
> Jan 2 19:29:30 buildroot kernel: Writing chunk 0 tags 257 0
> Jan 2 19:29:30 buildroot kernel: nandmtd2_WriteChunkWithTagsToNAND
> chunk 0 data c7ab8000 tags c7ae3db0
> Jan 2 19:29:30 buildroot kernel: packed tags obj 268435713 chunk
> -2147483647 byte 0 seq 4097
> Jan 2 19:29:30 buildroot kernel: ext.tags eccres 0 blkbad 0 chused 1
> obj 257 chunk0 byte 0 del 0 ser 1 seq 4097
> Jan 2 19:29:30 buildroot kernel: nand_base nand_write_page
> Jan 2 19:29:30 buildroot kernel: mxc_nd2.c mxc_nand_write_page
> Jan 2 19:29:30 buildroot kernel: NOT writelen
> Jan 2 19:29:30 buildroot kernel: ret is: 0
> Jan 2 19:29:30 buildroot kernel: param.writeChunkWithTagsToNAND
> YAFFS_OK
> Jan 2 19:29:30 buildroot kernel: write succeeded
> Jan 2 19:29:30 buildroot kernel: nandmtd2_ReadChunkWithTagsFromNAND
> chunk 0 data c7abf000 tags c7ae3be8
> Jan 2 19:29:30 buildroot kernel: yaffs_UnpackTags2TagsPart
> Jan 2 19:29:30 buildroot kernel: yaffs_UnpackTags2TagsPart in the if
> Jan 2 19:29:30 buildroot kernel: yaffs_UnpackTags2TagsPart intheif
> intheif
> Jan 2 19:29:30 buildroot kernel: packed tags obj -1 chunk -1 byte -1
> seq 4097
> Jan 2 19:29:30 buildroot kernel: ext.tags eccres 0 blkbad 0 chused 1
> obj 268435455 chunk0 byte 0 del 0 ser 0 seq 4097
> Jan 2 19:29:30 buildroot kernel: packed tags obj -1 chunk -1 byte -1
> seq 4097
> Jan 2 19:29:30 buildroot kernel: ext.tags eccres 1 blkbad 0 chused 1
> obj 268435455 chunk0 byte 0 del 0 ser 0 seq 4097
> Jan 2 19:29:31 buildroot kernel: nandmtd2_ReadChunkWithTagsFromNAND
> YAFFS_OK
> Jan 2 19:29:31 buildroot kernel:
> ======================================================
> Jan 2 19:29:31 buildroot kernel: tempTags.objectId=268435455,
> tags->objectId=257
> Jan 2 19:29:31 buildroot kernel: tempTags.chunkId=0, tags->chunkId=0
> Jan 2 19:29:31 buildroot kernel: tempTags.byteCount=0,
> tags->byteCount=0
> Jan 2 19:29:31 buildroot kernel:
> ======================================================
> Jan 2 19:29:31 buildroot kernel: yaffs_VerifyChunkWritten YAFFS_FAIL
> Jan 2 19:29:31 buildroot kernel: **>> Block 1 needs retiring
> Jan 2 19:29:31 buildroot kernel: line 602 delete of chunk 128
>
> Please don't mind the extra printouts I added to the code as some are
> not too pretty... (and it's late.. :) )
> It seems the only parameter that is not verified before and after the
> write is the objectId that somehow gets a different value from what was
> written.
>
> I tried finding out what was the reason for that but came up with
> nothing, I guess you can say I'm stuck.
>
> Can someone give me a clue as to what am I missing here?
>
> Boaz.
>
> On Fri, 2010-12-31 at 09:29 +0000, Laurie van Someren wrote:
> > On Thu, 2010-12-30 at 17:29 +0200, Boaz Ben-David wrote:
> >
> > It might be useful to study HOW YAFFS WORKS and have it to refer to,
> > so I have attached a copy.
> > LvS
> >
> >
> > > Hi Charles,
> > >
> > > Thanks for the info.
> > > I'm going over the code right now, I found the ecc layout structs.
> > > My question is: where can I find out the addresses yaffs writes to?
> > > I saw
> > >
> > > int nandmtd2_WriteChunkWithTagsToNAND(yaffs_Device *dev, int
> > > chunkInNAND, const __u8 *data, const yaffs_ExtendedTags *tags)
> > >
> > > has some calls to mtd->write_oob(mtd, addr, &ops);
> > > and started printing the addr out but then I wondered what exactly the
> > > addr means. Is it a real address in the chip or is it some kind of
> > > offset?
> > > I know I'm a bit lost here, and would very much appreciate your help.
> > >
> > > Thanks,
> > >
> > > Boaz.
> > >
> > >
> > > On Thu, 2010-12-30 at 11:06 +1300, Charles Manning wrote:
> > > > On Tuesday 28 December 2010 06:38:17 Ross Younger wrote:
> > > > > * Boaz Ben-David <boaz.bd@wellsense-tech.com> wrote:
> > > > > > My problem is that when I try to write some files (even using "touch")
> > > > > > it seems yaffs is trying to retire all of the blocks on the partition.
> > > > >
> > > > > Most problems I've encountered of this nature have been caused by bugs in
> > > > > the MTD driver(s). The root causes have been things like the MTD driver
> > > > > misreporting to YAFFS that the write failed, the write actually failing
> > > > > due to a protocol or timing error, or YAFFS believing there to be an
> > > > > ECC mismatch somewhere along the line. Particularly check the ECC -
> > > > > sometimes you have to special-case the check for empty pages (if the
> > > > > ECC for an erased block - all 0xFF - is not itself all 0xFF).
> > > > >
> > > > > You may be able to get more of an insight into exactly what has gone
> > > > > wrong by turning on tracing and working backwards from the exact error
> > > > > reported.
> > > > >
> > > > > Ross
> > > >
> > > > Ross is almost certainly right.
> > > >
> > > > The nand oob/spare area is generally split into three areas:
> > > > * bad block marker - typically 2 bytes at offset 0
> > > > * ECC bytes.
> > > > * oobferee used by yaffs to store tags.
> > > >
> > > > Eg there is a typical oob layout structure:
> > > >
> > > > static struct nand_ecclayout nand_oob_64 = {
> > > > .eccbytes = 24,
> > > > .eccpos = {
> > > > 40, 41, 42, 43, 44, 45, 46, 47,
> > > > 48, 49, 50, 51, 52, 53, 54, 55,
> > > > 56, 57, 58, 59, 60, 61, 62, 63},
> > > > .oobfree = {
> > > > {.offset = 2,
> > > > .length = 38}}
> > > > };
> > > >
> > > > The structure starts at offset 2 because the first two bytes are used by the
> > > > bad block marker.
> > > >
> > > > The yaffs tags reading/writing should be accessing oobfree.
> > > >
> > > > Some drivers get this wrong and reads/writes that should be accessing the
> > > > oobfree areas are instead accessing some other area. A typical mistake is to
> > > > not apply the layout and just access at offset 0. This causes problems
> > > > because the tags and bad block marker get mashed together.
> > > >
> > > > I suggest you work through the function calls to check that the right bytes
> > > > are being accessed.
> > > >
> > > > --- Charles
> > >
> > > _______________________________________________
> > > yaffs mailing list
> > > yaffs@lists.aleph1.co.uk
> > > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
> >
> > --
> > Laurie van Someren, Aleph One Ltd, Old Courthouse, Bottisham, CAMBRIDGE
> > CB25 9BA UK t: +44 (0)1 223 811 679 www.aleph1.co.uk & www.yaffs.net
> >
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
(text/plain)