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
>