Message ID | 20980858CB6D3A4BAE95CA194937D5E73EA51A1E@DBDE04.ent.ti.com |
---|---|
State | Superseded |
Delegated to: | Tom Rini |
Headers | show |
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
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;