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 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