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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EE8612C.9050104@freescale.com>
Date:	Wed, 14 Dec 2011 16:41:16 +0800
From:	LiuShuo <b35362@...escale.com>
To:	Scott Wood <scottwood@...escale.com>, <dedekind1@...il.com>
CC:	<shuo.liu@...escale.com>, <dwmw2@...radead.org>,
	<Artem.Bityutskiy@...ia.com>, <linux-mtd@...ts.infradead.org>,
	<linuxppc-dev@...ts.ozlabs.org>, <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <leoli@...escale.com>
Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support
 large-page Nand chip

于 2011年12月13日 10:46, LiuShuo 写道:
> 于 2011年12月13日 05:30, Scott Wood 写道:
>> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
>>> On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
>>>> 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
>>>> byte oob, 2k data, 64 byte oob" the marker is no longer in the 
>>>> oob.  On
>>>> first use we need to migrate the markers so that they are still in 
>>>> the oob.
>>> Ah, I see, thanks. Are you planning to implement in-kernel migration or
>>> 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
I found it's too complex to do the migration in Linux driver.

Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once is 
enough.
And let user ensure it been completed before linux use the Nand flash chip.

Even if we don't do the migration, the bad block also can be marked as bad
by wearing. So, do we really need to take much time to implement it ?
(code looks too complex.)

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/