[U-Boot] [PATCH v2 13/13] mxc nand: Add support for i.MX5

[Benoît Thébaudeau]

On Wednesday, November 21, 2012 12:03:47 AM, Scott Wood wrote:
> 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.

Indeed, you're right. After having seen this comment, I've looked for 16-bit
NANDs with a bad block marker on byte 11, but haven't found any. However, for
NFC v1 (e.g. i.MX31's), the reference manual gives this position for bad block
information for 16-bit spare area layout. I don't know why. This is really
weird. And the RM also says not to use this byte as general purpose, just like
ECC bytes, as if it were used by the NFC itself. Even if some NANDs exist
somewhere using this offset, they're far from being the most common, so I don't
know why the reference manual would mention this byte and not bytes 0 and 1.

Best regards,
Benoît