Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

=E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:30, Scott Wood =E5=86=99=
=E9=81=93:

On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:

quoted

On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:

quoted

NAND chips come from the factory with bad blocks marked at a certain
offset into each page.  This offset is normally in the OOB area, but
since we change the layout from "4k data, 128 byte oob" to "2k data, =

64

quoted

quoted

byte oob, 2k data, 64 byte oob" the marker is no longer in the oob.  =

On

quoted

quoted

first use we need to migrate the markers so that they are still in th=

e oob.

quoted

Ah, I see, thanks. Are you planning to implement in-kernel migration o=

r

quoted

use a user-space tool?

That's the kind of answer I was hoping to get from Shuo. :-)

OK, I try to do this. Wait for a couple of days.

-LiuShuo

Most likely is a firmware-based tool, but I'd like there to be some way
for the tool to mark that this has happened, so that the Linux driver
can refuse to do non-raw accesses to a chip that isn't marked as having
been migrated (or at least yell loudly in the log).

Speaking of raw accesses, these are currently broken in the eLBC
driver... we need some way for the generic layer to tell us what kind o=

f

access it is before the transaction starts, not once it wants to read
out the buffer (unless we add more hacks to delay the start of a read
transaction until first buffer access...).  We'd be better off with a
high-level "read page/write page" function that does the whole thing
(not just buffer access, but command issuance as well).

-Scott