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