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 >