On Friday 31 December 2010 04:29:28 Boaz Ben-David wrote:
> 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)
YAFFS is "log structured (ie. writes pages in sequence). This function just
writes a new chunk to the next page in NAND.
>
> 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?
addr is the nand address to be written to. This will be the address in nand of
the start of the page to be written.
This can be confusing because when you read, the actual address being read
will depend on whether the data or oob area of the page is being read. ie.
offset n in a page could mean offset n into the data part or the oob part.
> 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
(text/plain)