OK, it's all working now. the problem was that nand_read_ecc()
was doing the AUTOPLACE to skip the bad block marker, but the
same AUTOPLACE code did not exist in nand_read_oob(). And when
YAFFS2 calls through its yaffs_mtdif.c layer while its looking for
the right chunk ID, it ends up calling nand_read_oob()
and not nand_read_ecc(). So, I put the same AUTOPLACE code there
and wala, All works. It's a pain having to cobble together new
and old code so as to live in the past (2.4 kernel I mean).
I know its my own darn fault.
This is so FAST compared to JAFFS2. THANK YOU!!!!!
__________________________________
Reed Lawson
IGT Firmware Engineering
(775) 448-0755
> -----Original Message-----
> From: yaffs-bounces@stoneboat.aleph1.co.uk
> [mailto:yaffs-bounces@stoneboat.aleph1.co.uk]
> Sent: Thursday, July 07, 2005 7:26 PM
> To: yaffs@stoneboat.aleph1.co.uk
> Subject: Re: [Yaffs] RE: inadvertently marking all blocks bad?
>
>
> On Friday 08 July 2005 11:59, Lawson.Reed wrote:
> > First of all, My thoughts and prayers are with you in the UK
> > as you recover from this horrific attack on your country,
> > this slaughter of innocent people by those sick terrorist.
> > Just horrible....
>
> I'd like to express my condolances too. I expect the last
> Lions rugby match on
> Saturday here in Kiwi-land will have a more sombre tone than
> the last two.
>
> Anyway, back to YAFFS-biz...
>
> Generally any problems related to massive numbers of lost
> blocks or ones like
> you're having below are due to mtd interfacing rather than
> YAFFS issues per
> se.
>
> With the smaller 512-byte page devices (ie YAFFS1 format
> using YAFFS1 code or
> YAFFS2 code using the compatability layer), YAFFS does all
> the pacement and
> bad block marker handling itself. With the wider range of
> devices supported
> by YAFFS2 this is no longer possible and the mtd must provide
> the bad block
> handling.
>
> It is probably a good thing to disable bad block marking
> during initial
> bring-up to prevent the actual flash from getting hammered.
>
>
> > I wanted to let you know I found part of my problem. I did not have
> > useecc = MTD_NANDECC_AUTOPLACE. I had to do this
> > in my map driver:
> > igt_sn2_mtd->oobinfo.useecc = MTD_NANDECC_AUTOPLACE;
> > just before adding the partition.
>
> This and the problems you mention below are consistent wiuth
> a problem that
> Nick notices in the mtd where it was copying bytes
> incorrectly. I believe
> this has been fixed recently in mtd by Thomas.
>
> Are you running a recent mtd?
>
> >
> > then, I was getting an infinite loop because of this in
> > nand_prepare_oobbuf():
> >
> > for (i = 0, len = 0; len < mtd->oobavail; i++) {
> > int to = ofs + oobsel->oobfree[i][0];
> > int num = oobsel->oobfree[i][1];
> > memcpy (&this->oob_buf[to], fsbuf, num);
> > len += num;
> > fsbuf += num;
> > }
> > my mtd->oobavail was 39 and my oobsel->oobfree[0][1] was 38.
> > but the next one (oobsel->oobfree[1][1]) was 0 making "num"
> > zero so the loop went forever. That's pretty nasty.
> > I change mtd->oobavail to 38 and then it was happy. Humm.
> >
> > However, now I am getting tons of these when I remove a file
> > and copy another one in:
> >
> > page 130 in gc has no object
> > page 131 in gc has no object
> > page 132 in gc has no object
> > page 133 in gc has no object
> > page 134 in gc has no object
> > etc....
> >
> > Any ideas? Is it because I moved the stuff in the oob and now
> > someplace else can't find it? Is this MTD_NANDECC_AUTOPLACE
> > the right thing to set to avoid the zeroing out of the
> > bad block markers? or is there a better way?
>
> Basically these indicate that what was read back from NAND
> was not what got
> written to NAND. There was a bug in the auto-placement stuff
> that was copying
> the tags data incorrectly which would have caused object ids
> etc in the tags
> to get corrupted.
>
> Try the new mtd and see if that fixes things.
>
> -- Charles
>
> _______________________________________________
> yaffs mailing list
> yaffs@stoneboat.aleph1.co.uk
> http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
(text/plain)