From: LiuShuo <b35362@freescale.com>
To: Scott Wood <scottwood@freescale.com>, <dedekind1@gmail.com>
Cc: Artem.Bityutskiy@nokia.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, shuo.liu@freescale.com,
linux-mtd@lists.infradead.org, akpm@linux-foundation.org,
leoli@freescale.com, dwmw2@infradead.org
Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
Date: Fri, 16 Dec 2011 10:44:06 +0800 [thread overview]
Message-ID: <4EEAB076.30000@freescale.com> (raw)
In-Reply-To: <4EE903CE.1010903@freescale.com>
于 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
WARNING: multiple messages have this Message-ID (diff)
From: LiuShuo <b35362@freescale.com>
To: Scott Wood <scottwood@freescale.com>, <dedekind1@gmail.com>
Cc: Artem.Bityutskiy@nokia.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, shuo.liu@freescale.com,
linux-mtd@lists.infradead.org, akpm@linux-foundation.org,
dwmw2@infradead.org
Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
Date: Fri, 16 Dec 2011 10:44:06 +0800 [thread overview]
Message-ID: <4EEAB076.30000@freescale.com> (raw)
In-Reply-To: <4EE903CE.1010903@freescale.com>
=E4=BA=8E 2011=E5=B9=B412=E6=9C=8815=E6=97=A5 04:15, Scott Wood =E5=86=99=
=E9=81=93:
> On 12/14/2011 02:41 AM, LiuShuo wrote:
>> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 10:46, LiuShuo =E5=86=99=
=E9=81=93:
>>> =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:
>>>>> On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
>>>>>> NAND chips come from the factory with bad blocks marked at a certa=
in
>>>>>> offset into each page. This offset is normally in the OOB area, b=
ut
>>>>>> 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 migratio=
n 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 (possibl=
y
> 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=20
your help.
hi Artem,
Could this patch be applied now and we make a independent patch for bad=20
block information
migration later?
-LiuShuo
> -Scott
WARNING: multiple messages have this Message-ID (diff)
From: LiuShuo <b35362@freescale.com>
To: Scott Wood <scottwood@freescale.com>, <dedekind1@gmail.com>
Cc: <shuo.liu@freescale.com>, <dwmw2@infradead.org>,
<Artem.Bityutskiy@nokia.com>, <linux-mtd@lists.infradead.org>,
<linuxppc-dev@lists.ozlabs.org>, <akpm@linux-foundation.org>,
<linux-kernel@vger.kernel.org>, <leoli@freescale.com>
Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
Date: Fri, 16 Dec 2011 10:44:06 +0800 [thread overview]
Message-ID: <4EEAB076.30000@freescale.com> (raw)
In-Reply-To: <4EE903CE.1010903@freescale.com>
于 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
next prev parent reply other threads:[~2011-12-16 2:39 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-04 4:31 [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR shuo.liu
2011-12-04 4:31 ` shuo.liu
2011-12-04 4:31 ` shuo.liu
2011-12-04 4:31 ` [PATCH 2/3] mtd/nand : set correct length to FBCR for a non-full-page write shuo.liu
2011-12-04 4:31 ` shuo.liu
2011-12-04 4:31 ` shuo.liu
2011-12-04 4:31 ` [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip shuo.liu
2011-12-04 4:31 ` shuo.liu
2011-12-04 4:31 ` shuo.liu
2011-12-05 6:47 ` Artem Bityutskiy
2011-12-05 6:47 ` Artem Bityutskiy
2011-12-05 6:47 ` Artem Bityutskiy
2011-12-05 19:46 ` Scott Wood
2011-12-05 19:46 ` Scott Wood
2011-12-06 11:49 ` Artem Bityutskiy
2011-12-06 11:49 ` Artem Bityutskiy
2011-12-06 11:49 ` Artem Bityutskiy
2011-12-06 11:49 ` Artem Bityutskiy
2011-12-06 11:49 ` Artem Bityutskiy
2011-12-07 0:09 ` Scott Wood
2011-12-07 0:09 ` Scott Wood
2011-12-07 0:09 ` Scott Wood
2011-12-07 3:55 ` LiuShuo
2011-12-07 3:55 ` LiuShuo
2011-12-07 3:55 ` LiuShuo
2011-12-07 19:11 ` Scott Wood
2011-12-07 19:11 ` Scott Wood
2011-12-07 19:11 ` Scott Wood
2011-12-08 10:44 ` LiuShuo
2011-12-08 10:44 ` LiuShuo
2011-12-08 10:44 ` LiuShuo
2011-12-08 18:43 ` Scott Wood
2011-12-08 18:43 ` Scott Wood
2011-12-08 18:43 ` Scott Wood
2011-12-12 21:09 ` Artem Bityutskiy
2011-12-12 21:09 ` Artem Bityutskiy
2011-12-12 21:09 ` Artem Bityutskiy
2011-12-12 21:15 ` Scott Wood
2011-12-12 21:15 ` Scott Wood
2011-12-12 21:15 ` Scott Wood
2011-12-12 21:19 ` Artem Bityutskiy
2011-12-12 21:19 ` Artem Bityutskiy
2011-12-12 21:19 ` Artem Bityutskiy
2011-12-12 21:30 ` Scott Wood
2011-12-12 21:30 ` Scott Wood
2011-12-12 21:30 ` Scott Wood
2011-12-13 2:46 ` LiuShuo
2011-12-13 2:46 ` LiuShuo
2011-12-13 2:46 ` LiuShuo
2011-12-14 8:41 ` LiuShuo
2011-12-14 8:41 ` LiuShuo
2011-12-14 8:41 ` LiuShuo
2011-12-14 20:15 ` Scott Wood
2011-12-14 20:15 ` Scott Wood
2011-12-14 20:15 ` Scott Wood
2011-12-15 4:59 ` Li Yang
2011-12-15 4:59 ` Li Yang
2011-12-15 4:59 ` Li Yang
2011-12-15 17:32 ` Scott Wood
2011-12-15 17:32 ` Scott Wood
2011-12-16 2:44 ` LiuShuo [this message]
2011-12-16 2:44 ` LiuShuo
2011-12-16 2:44 ` LiuShuo
2011-12-16 17:59 ` Scott Wood
2011-12-16 17:59 ` Scott Wood
2011-12-16 17:59 ` Scott Wood
2011-12-19 11:05 ` Li Yang
2011-12-19 11:05 ` Li Yang
2011-12-19 11:05 ` Li Yang
2011-12-19 16:47 ` Scott Wood
2011-12-19 16:47 ` Scott Wood
2011-12-20 9:08 ` Li Yang
2011-12-20 9:08 ` Li Yang
2011-12-20 9:08 ` Li Yang
2011-12-20 19:48 ` Scott Wood
2011-12-20 19:48 ` Scott Wood
2011-12-17 14:35 ` Artem Bityutskiy
2011-12-17 14:35 ` Artem Bityutskiy
2011-12-17 14:35 ` Artem Bityutskiy
2011-12-19 18:38 ` Scott Wood
2011-12-19 18:38 ` Scott Wood
2011-12-19 18:38 ` Scott Wood
2011-12-19 18:42 ` Scott Wood
2011-12-19 18:42 ` Scott Wood
2011-12-14 3:41 ` LiuShuo
2011-12-14 3:41 ` LiuShuo
2011-12-14 3:41 ` LiuShuo
2011-12-14 20:53 ` Scott Wood
2011-12-14 20:53 ` Scott Wood
2011-12-14 20:53 ` Scott Wood
2011-12-05 6:50 ` [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR Artem Bityutskiy
2011-12-05 6:50 ` Artem Bityutskiy
2011-12-05 6:50 ` Artem Bityutskiy
-- strict thread matches above, loose matches on Subject: below --
2011-11-24 0:41 b35362
2011-11-24 0:41 ` [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip b35362
2011-11-24 0:41 ` b35362
2011-11-24 0:41 ` b35362
2011-11-24 7:37 ` Li Yang-R58472
2011-11-24 7:37 ` Li Yang-R58472
2011-11-24 7:37 ` Li Yang-R58472
2011-11-28 17:20 ` Scott Wood
2011-11-28 17:20 ` Scott Wood
2011-11-24 7:41 ` Artem Bityutskiy
2011-11-24 7:41 ` Artem Bityutskiy
2011-11-24 7:41 ` Artem Bityutskiy
2011-11-24 7:49 ` Li Yang-R58472
2011-11-24 7:49 ` Li Yang-R58472
2011-11-24 7:49 ` Li Yang-R58472
2011-11-24 8:16 ` Artem Bityutskiy
2011-11-24 8:16 ` Artem Bityutskiy
2011-11-24 10:02 ` LiuShuo
2011-11-24 10:02 ` LiuShuo
2011-11-24 10:02 ` LiuShuo
2011-11-24 11:07 ` Artem Bityutskiy
2011-11-24 11:07 ` Artem Bityutskiy
2011-11-28 21:48 ` Scott Wood
2011-11-28 21:48 ` Scott Wood
2011-11-28 21:48 ` Scott Wood
2011-11-28 21:49 ` Scott Wood
2011-11-28 21:49 ` Scott Wood
2011-11-28 21:49 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EEAB076.30000@freescale.com \
--to=b35362@freescale.com \
--cc=Artem.Bityutskiy@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=leoli@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=scottwood@freescale.com \
--cc=shuo.liu@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.