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
>
(text/plain)