From manningc2@actrix.gen.nz Fri Feb 19 01:09:02 2010 Received: from smtp.firstline.co.nz ([203.167.210.162] helo=firstline.co.nz) by stoneboat.aleph1.co.uk with smtp (Exim 4.69) (envelope-from ) id 1NiHMS-0000T4-E8 for yaffs@lists.aleph1.co.uk; Fri, 19 Feb 2010 01:09:02 +0000 Received: (qmail 26815 invoked by uid 453); 19 Feb 2010 01:08:37 -0000 X-Virus-Checked: Checked by ClamAV on firstline.co.nz Received: from Unknown (HELO linux-dual-head.local) (10.14.210.25) by firstline.co.nz (qpsmtpd/0.40) with ESMTP; Fri, 19 Feb 2010 14:08:37 +1300 From: Charles Manning To: yaffs@lists.aleph1.co.uk Date: Fri, 19 Feb 2010 14:08:35 +1300 User-Agent: KMail/1.9.10 References: <362486.35245.qm@web29118.mail.ird.yahoo.com> In-Reply-To: <362486.35245.qm@web29118.mail.ird.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201002191408.35960.manningc2@actrix.gen.nz> X-SA-Exim-Connect-IP: 203.167.210.162 X-SA-Exim-Mail-From: manningc2@actrix.gen.nz X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on stoneboat.aleph1.co.uk X-Spam-Level: X-Spam-Status: No, score=-1.9 required=4.5 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk) Subject: Re: [Yaffs] Fixed bug in YAFFS ? X-BeenThere: yaffs@lists.aleph1.co.uk X-Mailman-Version: 2.1.11 Precedence: list List-Id: Discussion of YAFFS NAND flash filesystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 01:09:02 -0000 On Friday 19 February 2010 00:45:37 Sven Van Asbroeck wrote: > Hello, > I think I've identified a small bug in YAFFS - and instead of merely > whingeing about it, I'll offer a patch that fixes it, how about that! > The problem is related to the 'inband-tags' option. I had to switch this > on, since the vendor's MTD driver (Freescale) does not allow access to the > NAND spare area at this point in time. After switching this on, everything > worked fine until a block had to be erased. That didn't work, and the MTD > driver complained about unaligned offsets and lengths. It turns out that > the mtd interface's NAND block erase function calculates the offsets and > lengths using dev->nDataBytesPerChunk. This will work fine as long as > 'inband-tags' is not specified, as dev->nDataBytesPerChunk == > dev->totalBytesPerChunk in that case. I've corrected this by using > dev->totalBytesPerChunk for the offset/length calculation. I must have done > something right, as YAFFS works very well now. > Hope this is useful, > Sven > > --- > linux/fs/yaffs2/yaffs_mtdif.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > diff --git a/linux/fs/yaffs2/yaffs_mtdif.c b/linux/fs/yaffs2/yaffs_mtdif.c > index aab9a12..be61233 100644 > --- a/linux/fs/yaffs2/yaffs_mtdif.c > +++ b/linux/fs/yaffs2/yaffs_mtdif.c > @@ -209,14 +209,14 @@ int nandmtd_EraseBlockInNAND(yaffs_Device *dev, int > blockNumber) { > struct mtd_info *mtd = (struct mtd_info *)(dev->genericDevice); > __u32 addr = > - ((loff_t) blockNumber) * dev->nDataBytesPerChunk > + ((loff_t) blockNumber) * dev->totalBytesPerChunk > * dev->nChunksPerBlock; > struct erase_info ei; > int retval = 0; > ei.mtd = mtd; > ei.addr = addr; > - ei.len = dev->nDataBytesPerChunk * dev->nChunksPerBlock; > + ei.len = dev->totalBytesPerChunk * dev->nChunksPerBlock; > ei.time = 1000; > ei.retries = 2; > ei.callback = NULL; > -- > 1.6.3.3 Hello Sven I confirm that was a bug. I should run inband tags through my test harnesses more often... I have corrected cvs. I have also cleared out some obsolete mtdif code. Thanks -- Charles