[PATCH 1/1] NDFC: add support for alternate ECC format for ndfc

[PATCH 1/1] NDFC: add support for alternate ECC format for ndfc

[Feng Kan]

This is to lock down the ordering in the correction routine against
the calculate routine. Otherwise, incorrect define would cause ECC errors.

Signed-off-by: Feng Kan <fkan@amcc.com>
Acked-by: Victor Gallardo <vgallardo@amcc.com>
---
 drivers/mtd/nand/ndfc.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 40b5658..fc1f0ff 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -102,10 +102,15 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
 	wmb();
 	ecc = in_be32(ndfc->ndfcbase + NDFC_ECC);
 	/* The NDFC uses Smart Media (SMC) bytes order */
+#ifdef CONFIG_MTD_NAND_ECC_SMC
 	ecc_code[0] = p[1];
 	ecc_code[1] = p[2];
 	ecc_code[2] = p[3];
+#else
+	ecc_code[0] = p[2];
+	ecc_code[1] = p[1];
+	ecc_code[2] = p[3];
+#endif

 	return 0;
 }
 
-- 
1.5.5

Re: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc

[Sean MacLennan]

On Thu, 18 Feb 2010 15:11:18 -0800
Feng Kan <fkan@amcc.com> wrote:

> This is to lock down the ordering in the correction routine against
> the calculate routine. Otherwise, incorrect define would cause ECC
> errors.

Did you actually find a 44x PPC core that is not NAND_ECC_SMS format?

Cheers,
   Sean

RE: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc

[Feng Kan]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

Hi Sean:
 
I will withdraw this patch. I had a talk with the U-Boot guys. The reason for this
patch was to support those guys that had their ECC ordering at (213) on the older
version of the kernel. Upgrading to (123) may be problematic. Since without a jtag
it would be a bit complex. 
 
I still think this NAND_ECC_SMC define is somewhat missleading. Given that
both 1-2-3 and 2-1-3 are supported by the correction routine.
Feng

________________________________

From: Sean MacLennan [mailto:smaclennan@pikatech.com]
Sent: Sat 2/20/2010 5:11 PM
To: Feng Kan
Cc: linux-mtd@lists.infradead.org; linuxppc-dev@ozlabs.org; Feng Kan
Subject: Re: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc



On Thu, 18 Feb 2010 15:11:18 -0800
Feng Kan <fkan@amcc.com> wrote:

> This is to lock down the ordering in the correction routine against
> the calculate routine. Otherwise, incorrect define would cause ECC
> errors.

Did you actually find a 44x PPC core that is not NAND_ECC_SMS format?

Cheers,
   Sean



[-- Attachment #2: Type: text/html, Size: 2042 bytes --]

Re: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc

[Sean MacLennan]

On Mon, 22 Feb 2010 21:21:53 -0800
"Feng Kan" <fkan@amcc.com> wrote:

> Hi Sean:
>  
> I will withdraw this patch. I had a talk with the U-Boot guys. The
> reason for this patch was to support those guys that had their ECC
> ordering at (213) on the older version of the kernel. Upgrading to
> (123) may be problematic. Since without a jtag it would be a bit
> complex. 
> I still think this NAND_ECC_SMC define is somewhat missleading. Given
> that both 1-2-3 and 2-1-3 are supported by the correction routine.

The 213 ordering is my fault. I changed it to match what u-boot did
rather than keeping the order from the old arch-ppc driver. Believe
me, I have been raked over the coals at work for this :(

I agree the NAND_ECC_SMC is misleading. The NAND_ECC_SMC *is* correct.
The confusion is that the SMC is handled later on, so you must keep the
byte order unaltered in this routine.

I wrote a simple driver that allows you to boot with the old kernel,
insmod the driver, burn new images (including a kernel with the correct
byte order!), and then reboot into the new kernel. If anybody wants
this, just ask. It will take a little work to get it working with other
NANDs since it needs to know the NAND name to get the mtd structure.

It also assumes you have a way to write to NAND in user mode. The
mtd-utils flash_eraseall and nandwrite are good enough.

Cheers,
   Sean