From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 20 Nov 2012 17:03:47 -0600 Subject: [U-Boot] [PATCH v2 13/13] mxc nand: Add support for i.MX5 In-Reply-To: <1412352961.1504022.1353116583053.JavaMail.root@advansee.com> (from benoit.thebaudeau@advansee.com on Fri Nov 16 19:43:03 2012) References: <1353110463.13910.7@snotra> <1412352961.1504022.1353116583053.JavaMail.root@advansee.com> Message-ID: <1353452627.2863.11@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11/16/2012 07:43:03 PM, Beno?t Th?baudeau wrote: > Hi Scott, > > On Saturday, November 17, 2012 1:01:03 AM, Scott Wood wrote: > > On 11/16/2012 02:28:16 PM, Beno?t Th?baudeau wrote: > > > Also, I've noticed that some of the oobfree fields of the > > > nand_ecclayout > > > structures in mxc_nand.c are slightly different from what can be > > > found in Linux. > > > Any idea about which one is correct (if any)? > > > > Unless there's an obvious error such as overlap with ECC or a bad > > block > > marker, there isn't really a right answer (except to the extent that > > you're wasting bytes) -- but it's important that everyone agree. So > > the answer is basically, "which compatibility would it hurt more to > > break?" > > > > That said, the U-Boot ones make more sense to me in terms of not > > having > > strange missing bytes. > > I've just found this commit, which explains what's going on: > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=8c1fd89a85f898384df02217c09c98c2f39b4832 I don't understand the bit about "on 16bit flashes it is on byte 11" -- I thought with 16-bit NAND the bad block marker was always at offset zero, even on small-page NAND. -Scott