| Message ID | 1266534678-30293-1-git-send-email-fkan@amcc.com (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
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
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
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
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; }