From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Wed, 04 Dec 2013 13:38:52 +0100 Subject: [U-Boot] Fwd: [PATCH v4] arm: omap3: Add SPL support to cm_t35 In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA51A1E@DBDE04.ent.ti.com> References: <1384501860-16881-1-git-send-email-sr@denx.de> <5288BBAC.2020307@compulab.co.il> <5295BF6C.20902@compulab.co.il> <5295C3F8.50101@denx.de> <529E01B7.4070402@compulab.co.il> <529F1428.7050804@denx.de> <20980858CB6D3A4BAE95CA194937D5E73EA51A1E@DBDE04.ent.ti.com> Message-ID: <529F225C.5090408@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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