From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 21 Aug 2012 15:39:21 -0500 Subject: [U-Boot] [PATCH v2 3/5] at91: atmel_nand: Update driver to support Programmable Multibit ECC controller In-Reply-To: <503364E6.5090104@atmel.com> References: <1345093515-16761-1-git-send-email-josh.wu@atmel.com> <1345093515-16761-4-git-send-email-josh.wu@atmel.com> <502E0DC4.3040904@gmail.com> <503364E6.5090104@atmel.com> Message-ID: <5033F1F9.6050706@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 08/21/2012 05:37 AM, Josh Wu wrote: > Hi, Andreas > > On 8/17/2012 5:24 PM, Andreas Bie?mann wrote: >> can you please add some README entry describing these new config >> parameters? >> Namely CONFIG_ATMEL_NAND_HW_PMECC, CONFIG_PMECC_CAP, >> CONFIG_PMECC_SECTOR_SIZE (can't this be derived from some already >> available NAND information?) and CONFIG_PMECC_INDEX_TABLE_OFFSET. > > OK, I will add a README file to explain all the parameters. > this CONFIG_PMECC_SECTOR_SIZE means how many bytes to generate out PMECC > code. It only can be 512 and 1024. > So for a nand chip whose page size is 2048, if CONFIG_PMECC_SECTOR_SIZE > is set as 512, then PMECC will generate PMECC code for each 512 bytes. > > I think it cannot be derived from nand information. So this is basically nand->ecc.size? While this can't be directly read from the chip, usually there's a convention for a given type of NAND chip on a given controller. Do you really need to support both 512 and 1024 for any single chip? Why do you set nand->ecc.size to mtd->writesize if that isn't the actual ECC chunk size? -Scott