From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Thu, 15 Dec 2011 11:36:08 -0600 Subject: [U-Boot] [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to support 4k pagesize Nand chip In-Reply-To: <3F453DDFF675A64A89321A1F352810216C4934@039-SN1MPN1-005.039d.mgd.msft.net> References: <1323683398-11001-1-git-send-email-Shengzhou.Liu@freescale.com> <1323683398-11001-2-git-send-email-Shengzhou.Liu@freescale.com> <1323683398-11001-3-git-send-email-Shengzhou.Liu@freescale.com> <1323683398-11001-4-git-send-email-Shengzhou.Liu@freescale.com> <1323683398-11001-5-git-send-email-Shengzhou.Liu@freescale.com> <4EE66099.3040100@freescale.com> <3F453DDFF675A64A89321A1F352810216BEF66@039-SN1MPN1-005.039d.mgd.msft.net> <4EE8E2E9.3050705@freescale.com> <3F453DDFF675A64A89321A1F352810216C4934@039-SN1MPN1-005.039d.mgd.msft.net> Message-ID: <4EEA3008.3080502@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 12/15/2011 04:53 AM, Liu Shengzhou-B36685 wrote: >>>> -----Original Message----- >>>> From: Wood Scott-B07421 >>>> Sent: Tuesday, December 13, 2011 4:14 AM >>>> To: Liu Shengzhou-B36685 >>>> Cc: u-boot at lists.denx.de; Gala Kumar-B11780; Liu Shuo-B35362 >>>> Subject: Re: [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to >>>> support 4k pagesize Nand chip >> >>>>> + nand->ecc.layout = (priv->fmr & FMR_ECCM) ? >>>>> + &fsl_elbc_oob_lp_eccm1 : &fsl_elbc_oob_lp_eccm0; >>>>> + nand->badblock_pattern = &largepage_memorybased; >>>> >>>> Those oob layouts won't be quite right for larger page sizes. >>>> >>>> -Scott >>> [Shengzhou] It's the same with what Linux does. What's the right? >> >> I think we need to explicitly define 4096 and 8192 variants, with the >> extra eccpos/oobfree. Or generate them programatically. >> >> -Scott > > [Shengzhou] > You mean we should define something like below? > static struct nand_ecclayout fsl_elbc_oob_lp_4k_eccm0 = { > .eccbytes = 24, > .eccpos = {6, 7, 8, 22, 23, 24, 38, 39, 40, 54, 55, 56, > 70, 71, 72, 86, 87, 88, 102, 103, 104, 118, 119, 120}, > .oobfree = { {1, 5}, {9, 13}, {25, 13}, {41, 13}, {57, 7},...... }, > }; > static struct nand_ecclayout fsl_elbc_oob_lp_8k_eccm0 = {........}; Yes. > eLBC RM says: > ECC is checked/calculated over 512-Byte blocks. A 24-bit ECC is assigned to spare region bytes at offsets > (N ? 16) + 6 through (N ? 16) + 8 for spare region N, N = 0?3. (for ECCM=0 case) > > Here RM just says N is 0?3, but it should be 0-7 for 4096 case, Well, yes, this is a hack to do things that the hardware doesn't officially support. > hardware ECC doesn't generate ECC in position of N=4,5,6,7. It will. It just thinks that N=0,1,2,3. > fsl_elbc_oob_lp_eccm0 and fsl_elbc_oob_lp_eccm1 are controller-associated, not device-associated, Then why do we have separate small and large page versions? > I think we don't need define 4096 and 8192 variants, it's emulating 4096/8192 case by > the existing 2K layout of fsl_elbc_oob_lp_eccm0 and fsl_elbc_oob_lp_eccm1. > Please correct me if any wrong understanding. It's supporting 4096/8192 by repeating the 2048 layout multiple times. This repetition is not captured by the existing nand_ecclayout. -Scott