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