From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpauth02.csee.onr.siteprotect.com ([64.26.60.136]) by bombadil.infradead.org with esmtp (Exim 4.68 #1 (Red Hat Linux)) id 1KV8Pb-0006HP-I9 for linux-mtd@lists.infradead.org; Mon, 18 Aug 2008 17:20:59 +0000 Message-ID: <48A9AF73.2040105@boundarydevices.com> Date: Mon, 18 Aug 2008 10:20:51 -0700 From: Troy Kisky MIME-Version: 1.0 To: Frans Meulenbroeks Subject: Re: [RESUBMIT] [PATCH] [MTD] NAND nand_ecc.c: rewrite for improved performance References: <1218789997.3184.64.camel@pmac.infradead.org> <1218793271.3184.77.camel@pmac.infradead.org> <1218795140.3184.84.camel@pmac.infradead.org> <48A5D154.2000409@boundarydevices.com> <48A8937D.1010007@boundarydevices.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-mtd@lists.infradead.org, David Woodhouse List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Frans Meulenbroeks wrote: > Yes, the NSLU2 had a filesystem that was created before the patch was applied. > But actually I think the filesystem is irrelevant. > I verified the proper operation by comparing the values generated by > the original code with the values generated by my code over a set of > input blocks. > Guess there is no endianness dependency and that if the data is big > endian the ecc is too. > > Frans. > Does that make logical sense to you? The correction routine accesses the data as a byte and flips a bit. If it accessed it as an uint32 and flipped the bit, then I can see that there would be no endianness dependency. I'm not suggesting you do that, as it would be incompatible with current ecc, just explaining my logic. I'd very much appreciate an explanation of why I'm wrong. I would expect big endian ecc to have 4 bits differences whenever the entire block parity is odd. These would be the bits that select the byte within the uint32. Troy