public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to support 4k pagesize Nand chip
Date: Thu, 15 Dec 2011 11:36:08 -0600	[thread overview]
Message-ID: <4EEA3008.3080502@freescale.com> (raw)
In-Reply-To: <3F453DDFF675A64A89321A1F352810216C4934@039-SN1MPN1-005.039d.mgd.msft.net>

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

  parent reply	other threads:[~2011-12-15 17:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-12  9:49 [U-Boot] [PATCH 1/5 v2] mtd/nand: Add function board_nand_init_tail() for some special NAND controllers Shengzhou Liu
2011-12-12  9:49 ` [U-Boot] [PATCH 2/5 v2] mtd/nand: Fixup for support ONFI detect Shengzhou Liu
2011-12-12  9:49   ` [U-Boot] [PATCH 3/5 v2] mtd/nand: remove CONFIG_SYS_NAND_ONFI_DETECTION to enable ONFI detection Shengzhou Liu
2011-12-12  9:49     ` [U-Boot] [PATCH 4/5 v2] mtd/nand: Add ONFI support for FSL NAND controller Shengzhou Liu
2011-12-12  9:49       ` [U-Boot] [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to support 4k pagesize Nand chip Shengzhou Liu
2011-12-12 20:14         ` Scott Wood
     [not found]           ` <3F453DDFF675A64A89321A1F352810216BEF66@039-SN1MPN1-005.039d.mgd.msft.net>
2011-12-14 17:54             ` Scott Wood
     [not found]               ` <3F453DDFF675A64A89321A1F352810216C4934@039-SN1MPN1-005.039d.mgd.msft.net>
2011-12-15 17:36                 ` Scott Wood [this message]
2012-01-10 23:29       ` [U-Boot] [PATCH 4/5 v2] mtd/nand: Add ONFI support for FSL NAND controller Scott Wood
2011-12-12 18:42     ` [U-Boot] [PATCH 3/5 v2] mtd/nand: remove CONFIG_SYS_NAND_ONFI_DETECTION to enable ONFI detection Scott Wood
     [not found]       ` <3F453DDFF675A64A89321A1F352810216BECF4@039-SN1MPN1-005.039d.mgd.msft.net>
2011-12-14 18:08         ` 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=4EEA3008.3080502@freescale.com \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox