From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Date: Mon, 10 Aug 2015 09:17:27 +0800 Subject: [U-Boot] [PATCH resend V2 1/3] mtd: nand: mxs support oobsize bigger than 512 In-Reply-To: <20150802031835.GA31590@shlinux2> References: <1437466521-27856-1-git-send-email-Peng.Fan@freescale.com> <201508011718.10214.marex@denx.de> <1438453927.2097.10.camel@freescale.com> <201508012038.54495.marex@denx.de> <1438455288.2097.17.camel@freescale.com> <20150802031835.GA31590@shlinux2> Message-ID: <20150810011723.GA15681@shlinux2> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Scott, Do you have plan to pick the 3 patches? https://patchwork.ozlabs.org/patch/498050/ https://patchwork.ozlabs.org/patch/498049/ https://patchwork.ozlabs.org/patch/498048/ If not, then I prefer these 3 patches can go throught i.mx tree. Thanks, Peng. On Sun, Aug 02, 2015 at 11:18:38AM +0800, Peng Fan wrote: >On Sat, Aug 01, 2015 at 01:54:48PM -0500, Scott Wood wrote: >>On Sat, 2015-08-01 at 20:38 +0200, Marek Vasut wrote: >>> On Saturday, August 01, 2015 at 08:32:07 PM, Scott Wood wrote: >>> > On Sat, 2015-08-01 at 17:18 +0200, Marek Vasut wrote: >>> > > On Saturday, August 01, 2015 at 07:56:39 AM, Peng Fan wrote: >>> > > > On Fri, Jul 31, 2015 at 09:36:45PM -0500, Scott Wood wrote: >>> > > > > On Sat, 2015-08-01 at 09:15 +0800, Peng Fan wrote: >>> > > > > > On Fri, Jul 31, 2015 at 12:07:50PM -0500, Scott Wood wrote: >>> > > > > > > On Tue, 2015-07-21 at 16:15 +0800, Peng Fan wrote: >>> > > > > > > > If ecc chunk data size is 512 and oobsize is bigger than 512, >>> > > > > > > > there >>> > > > > > > > is a chance that block_mark_bit_offset conflicts with bch ecc >>> > > > > > > > area. >>> > > > > > > > >>> > > > > > > > The following graph is modified from kernel gpmi-nand.c driver >>> > > > > > > > with >>> > > > > > > > each data block 512 bytes. We can see that Block Mark >>> > > > > > > > conflicts >>> > > > > > > > with >>> > > > > > > > ecc area from bch view. We can enlarge the ecc chunk size to >>> > > > > > > > avoid this problem to those oobsize which is larger than 512. >>> > > > > > > >>> > > > > > > Enlarge it by how much? What does the layout look like in that >>> > > > > > > case? >>> > > > > > >>> > > > > > Enlarge it to 1024 bytes. >>> > > > > >>> > > > > Then say so in the changelog. >>> > > > >>> > > > You mean I need to add this in commit msg and send out a new patch >>> > > > version? >>> > > > Or you pick this one? >>> > > >>> > > This discussion is becoming ridiculous, can we please get this bugfix >>> > > applied ? >>> > > If you don't like some minor details in the commit message, can you >>> > > please fix >>> > > them while applying ? >>> > >>> > Yes, I can edit the changelog while applying, but that doesn't mean I'm >>> > not >>> > going to complain about a difficult-to-understand changelog, and I still >>> > would like to understand what is actually going on here. Don't assume I'm >>> > familiar with this hardware or its unusual page layout. You can help by >>> > explaining things, or you can not help by throwing a fit... >>> >>> I can point you to MX28 datasheet [1] chapter 16.2.2 and onward if you want >>> to educate yourself, it's all explained there, concisely and clearly. >>> >>> [1] http://free-electrons.com/~maxime/pub/datasheet/MCIMX28RM.pdf >> >>Thanks. That preempted a question I was just about to ask Peng, because it >>wasn't clear that the meta area was covered by ECC. > >In mxs_nand.c driver, we use "Combined Metadata & Block 0, unbalanced ECC coverage" layout from chapter 16.2.2 of MX28 datasheet. > >Peng. >> >>-Scott >> > >-- --