lkml.org 
[lkml]   [2011]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
于 2011年12月15日 04:15, Scott Wood 写道:
> On 12/14/2011 02:41 AM, LiuShuo wrote:
>> 于 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.
> Any reason not to do it automatically on the first U-Boot bad block
> scan, if the flash isn't marked as already migrated?
>
> Further discussion on the details of how to do it in U-Boot should move
> to the U-Boot list.
>
>> And let user ensure it been completed before linux use the Nand flash chip.
> I don't want to trust the user here. It's too easy to skip it, and
> things will appear to work, but have subtle problems.
>
>> 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.)
> It is not acceptable to ignore factory bad block markers just because
> some methods of using the flash may eventually detect an error (possibly
> after data is lost -- no guarantee that the badness is ECC-correctable)
> and mark the block bad again.
>
> If you don't feel up to the task, I can look at it, but won't have time
> until January.
hi Scott,
It's really hard to me and I have much other works to do now. Thanks for
your help.

hi Artem,
Could this patch be applied now and we make a independent patch for bad
block information
migration later?

-LiuShuo

> -Scott


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

\
 
 \ /
  Last update: 2011-12-16 03:41    [W:1.451 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site