From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 22 Jan 2015 08:09:19 +0100 Subject: [U-Boot] [PATCH 2/2] mtd:mxs:nand support oobsize bigger than 512 In-Reply-To: <54BE5449.6070609@freescale.com> References: <1418963953-1623-1-git-send-email-Peng.Fan@freescale.com> <201501201203.49418.marex@denx.de> <54BE5449.6070609@freescale.com> Message-ID: <201501220809.20062.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tuesday, January 20, 2015 at 02:12:41 PM, Peng Fan wrote: > Hi, Marek > > On 1/20/2015 7:03 PM, Marek Vasut wrote: > > On Friday, December 19, 2014 at 05:39:13 AM, 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. > > > > What exactly is the impact of this patch for current installations of > > U-Boot? Does the NAND need to be rewritten with new content? Is the > > format introduced by this patch compatible with Linux? > > The patch does not affect current installations of U-boot. The NAND > will not be rewritten with new content for chips whose oobsize is > smaller than 512. To chips whose oobsize is bigger than 512, new > format(saying gf_len is 14 and ecc chunk data size is 1024) introduced > in this patch will be used. > > This patch is to support nand chips whose oobsize bigger than 512, since > the current mxs nand driver only supports oobisze smaller than 512. Data > maybe corrupted if oobsize is bigger than 512 while ecc chunk data size > is still 512, this is what this patch is try to fix. Yeah the format is > compatible with gpmi-nand.c in linux. Thanks for clarifying. Reviewed-by: Marek Vasut Best regards, Marek Vasut