[U-Boot] Fwd: [PATCH v4] arm: omap3: Add SPL support to cm_t35

[Gupta, Pekon]

Hi Stefan,

>From: Stefan Roese [mailto:sr at denx.de]
> >On 03.12.2013 17:07, Nikita Kiryanov wrote:
[...]
>> When based on v2014.01-rc1, SPL itself doesn't boot from NAND (no SPL
>> header or any visible activity when booting from NAND).
>
>Yes. I have now tested this as well. I have been digging into this a bit
>this morning. And it seems that this patch is causing the regression:
>
>d016dc42 [mtd: nand: omap: enable BCH ECC scheme using ELM for generic
>platform]
>
>I can only suspect that with this patch applied, U-Boot writes the SPL
>(MLO) to NAND in an incompatible way for the BootROM. I have switched to
>1bit HW ECC of course.
>
>Very strangely, the Technexion TAO3530 board works fine with SPL. Even
>with current mainline. The only difference I can see right now is, that
>TAO3530 has an 16bit NAND chip and the CM_T35 has an 8bit NAND chip.
>
For HAM1_HW this selects ecc-scheme as below..
@@omap_select_ecc_scheme()
   case OMAP_ECC_HAM1_CODE_HW:
+               /* define ecc-layout */
+               ecclayout->eccbytes     = nand->ecc.bytes * eccsteps;
+               for (i = 0; i < ecclayout->eccbytes; i++)
+                       ecclayout->eccpos[i] = i + BADBLOCK_MARKER_LENGTH;
+               ecclayout->oobfree[0].offset = i + BADBLOCK_MARKER_LENGTH;
+               ecclayout->oobfree[0].length = oobsize - ecclayout->eccbytes -
+                                               BADBLOCK_MARKER_LENGTH;

Aah!!... May be I understand the issue..
Reference: As per OMAP3530 TRM given below
	http://www.ti.com/product/omap3530
	http://www.ti.com/litv/pdf/spruf98x
	Chapter-25: Initialization 
		Sub-topic: Memory Booting
			Section: 25.4.7.4 NAND
			Figure 25-19. ECC Locations in NAND Spare Areas
  For large-page NAND
(a) x8 Device: ECC signature starts from  byte[1] in OOB (offset of 1 *byte*)
(b) x16 Device: ECC signature starts from byte[2] in OOB (offset of 1 *word*)

And in omap_gpmc.c  .. BADBLOCK_MARKER_LENGTH = 2.
So ECC signature starts from offset
                       ecclayout->eccpos[0] = 0 + BADBLOCK_MARKER_LENGTH = 0x2;
which is actually for (b) that is x16 device.

Thus, Technexion TAO3530 board with x16 NAND device is booting correctly,
Whereas CM_T35 with x8 NAND device fails..



>Unfortunately I have to stop debugging this issue now. Perhaps Pekon has
>an idea on whats going on here. Pekon, do you have an OMAP3530 board
>with an 8bit NAND chip? Or do you have any other idea, what might cause
>this problem?
>
It's a bug in driver. I should have taken care of device-width while defining
the layout. I think this is the issue with HAM1 scheme only, because ROM
code has same ecc-layout for other schemes (like BCH8) whether it's a
x8 or x16 devices.
Please patch following to see if CM_T35 boots fine, with latest u-boot.

diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index bf43520..99dfcc6 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -626,7 +626,10 @@ static int omap_select_ecc_scheme(struct nand_chip *nand,
                /* define ecc-layout */
                ecclayout->eccbytes     = nand->ecc.bytes * eccsteps;
                for (i = 0; i < ecclayout->eccbytes; i++)
-                       ecclayout->eccpos[i] = i + BADBLOCK_MARKER_LENGTH;
+                       if (nand->options & NAND_BUSWIDTH_16)
+                               ecclayout->eccpos[i] = i + 2;
+                       else
+                               ecclayout->eccpos[i] = i + 1;
                ecclayout->oobfree[0].offset = i + BADBLOCK_MARKER_LENGTH;
                ecclayout->oobfree[0].length = oobsize - ecclayout->eccbytes -
                                                BADBLOCK_MARKER_LENGTH;

Thanks for pointing out this..
Sorry I don't have many OMAP3 boards to boot-test HAM1, so this error crept in.
Once you confirm its working, I'll submit a formal patch.

with regards, pekon