diff for duplicates of <4EE8612C.9050104@freescale.com> diff --git a/a/1.txt b/N1/1.txt index 7614562..e462fb4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,16 +1,19 @@ -于 2011年12月13日 10:46, LiuShuo 写道: -> 于 2011年12月13日 05:30, Scott Wood 写道: +=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 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 +>>>> since we change the layout from "4k data, 128 byte oob" to "2k=20 >>>> data, 64 ->>>> byte oob, 2k data, 64 byte oob" the marker is no longer in the +>>>> byte oob, 2k data, 64 byte oob" the marker is no longer in the=20 >>>> oob. On ->>>> first use we need to migrate the markers so that they are still in +>>>> first use we need to migrate the markers so that they are still in=20 >>>> the oob. ->>> Ah, I see, thanks. Are you planning to implement in-kernel migration or +>>> 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. @@ -18,23 +21,28 @@ > -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 +Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once is=20 enough. -And let user ensure it been completed before linux use the Nand flash chip. +And let user ensure it been completed before linux use the Nand flash chi= +p. -Even if we don't do the migration, the bad block also can be marked as bad +Even if we don't do the migration, the bad block also can be marked as ba= +d 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 +>> Most likely is a firmware-based tool, but I'd like there to be some wa= +y >> 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 +>> can refuse to do non-raw accesses to a chip that isn't marked as havin= +g >> 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 +>> 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 diff --git a/a/content_digest b/N1/content_digest index 948ab9c..c1cb93c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -17,23 +17,25 @@ shuo.liu@freescale.com linux-mtd@lists.infradead.org akpm@linux-foundation.org - leoli@freescale.com " dwmw2@infradead.org\0" "\00:1\0" "b\0" - "\344\272\216 2011\345\271\26412\346\234\21013\346\227\245 10:46, LiuShuo \345\206\231\351\201\223:\n" - "> \344\272\216 2011\345\271\26412\346\234\21013\346\227\245 05:30, Scott Wood \345\206\231\351\201\223:\n" + "=E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 10:46, LiuShuo =E5=86=99=E9=\n" + "=81=93:\n" + "> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:30, Scott Wood =E5=86=99=\n" + "=E9=81=93:\n" ">> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:\n" ">>> On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:\n" ">>>> NAND chips come from the factory with bad blocks marked at a certain\n" ">>>> offset into each page. This offset is normally in the OOB area, but\n" - ">>>> since we change the layout from \"4k data, 128 byte oob\" to \"2k \n" + ">>>> since we change the layout from \"4k data, 128 byte oob\" to \"2k=20\n" ">>>> data, 64\n" - ">>>> byte oob, 2k data, 64 byte oob\" the marker is no longer in the \n" + ">>>> byte oob, 2k data, 64 byte oob\" the marker is no longer in the=20\n" ">>>> oob. On\n" - ">>>> first use we need to migrate the markers so that they are still in \n" + ">>>> first use we need to migrate the markers so that they are still in=20\n" ">>>> the oob.\n" - ">>> Ah, I see, thanks. Are you planning to implement in-kernel migration or\n" + ">>> Ah, I see, thanks. Are you planning to implement in-kernel migration =\n" + "or\n" ">>> use a user-space tool?\n" ">> That's the kind of answer I was hoping to get from Shuo. :-)\n" "> OK, I try to do this. Wait for a couple of days.\n" @@ -41,23 +43,28 @@ "> -LiuShuo\n" "I found it's too complex to do the migration in Linux driver.\n" "\n" - "Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once is \n" + "Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once is=20\n" "enough.\n" - "And let user ensure it been completed before linux use the Nand flash chip.\n" + "And let user ensure it been completed before linux use the Nand flash chi=\n" + "p.\n" "\n" - "Even if we don't do the migration, the bad block also can be marked as bad\n" + "Even if we don't do the migration, the bad block also can be marked as ba=\n" + "d\n" "by wearing. So, do we really need to take much time to implement it ?\n" "(code looks too complex.)\n" "\n" "-LiuShuo\n" "\n" - ">> Most likely is a firmware-based tool, but I'd like there to be some way\n" + ">> Most likely is a firmware-based tool, but I'd like there to be some wa=\n" + "y\n" ">> for the tool to mark that this has happened, so that the Linux driver\n" - ">> can refuse to do non-raw accesses to a chip that isn't marked as having\n" + ">> can refuse to do non-raw accesses to a chip that isn't marked as havin=\n" + "g\n" ">> been migrated (or at least yell loudly in the log).\n" ">>\n" ">> Speaking of raw accesses, these are currently broken in the eLBC\n" - ">> driver... we need some way for the generic layer to tell us what kind of\n" + ">> driver... we need some way for the generic layer to tell us what kind =\n" + "of\n" ">> access it is before the transaction starts, not once it wants to read\n" ">> out the buffer (unless we add more hacks to delay the start of a read\n" ">> transaction until first buffer access...). We'd be better off with a\n" @@ -67,4 +74,4 @@ ">> -Scott\n" > -d1f4aa69ac91e18495cb64ff3767ecc84c818914c4158c3b81c4930635d519d3 +41c9367aba5dc6b827c67524f58f941358f66e3b0cd03ae1c1a964da373b2c81
diff --git a/a/content_digest b/N2/content_digest index 948ab9c..e9601bf 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -11,14 +11,14 @@ "Date\0Wed, 14 Dec 2011 16:41:16 +0800\0" "To\0Scott Wood <scottwood@freescale.com>" " <dedekind1@gmail.com>\0" - "Cc\0Artem.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\0" + "Cc\0<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>\0" "\00:1\0" "b\0" "\344\272\216 2011\345\271\26412\346\234\21013\346\227\245 10:46, LiuShuo \345\206\231\351\201\223:\n" @@ -67,4 +67,4 @@ ">> -Scott\n" > -d1f4aa69ac91e18495cb64ff3767ecc84c818914c4158c3b81c4930635d519d3 +403b686aee5dce79c1c367ec585fd0b9e724c0107e5034310bc05fe471a4dbed
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.