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

[Stefan Roese]

Pekon!

On 04.12.2013 13:15, Gupta, Pekon wrote:
>> 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..

Sounds like a very good explanation. Thanks!

>> 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.

Yes. This fixes this issue on the cm-t35 board. So please submit a
proper patch. :)

Thanks again for this quick fix!
Stefan