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...
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