From patchwork Wed Dec 4 12:15:25 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: pekon gupta X-Patchwork-Id: 296501 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from theia.denx.de (theia.denx.de [85.214.87.163]) by ozlabs.org (Postfix) with ESMTP id 7E4EE2C007A for ; Wed, 4 Dec 2013 23:16:18 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 258BA4B604; Wed, 4 Dec 2013 13:16:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4-drcK+1Fdn; Wed, 4 Dec 2013 13:16:16 +0100 (CET) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 00C954B619; Wed, 4 Dec 2013 13:16:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 791D74B617 for ; Wed, 4 Dec 2013 13:16:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeOyiU6AUfVY for ; Wed, 4 Dec 2013 13:15:54 +0100 (CET) X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 (only DNSBL check requested) Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by theia.denx.de (Postfix) with ESMTPS id 543394B604 for ; Wed, 4 Dec 2013 13:15:46 +0100 (CET) Received: from dbdlxv05.itg.ti.com ([172.24.171.60]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id rB4CFSpl015723; Wed, 4 Dec 2013 06:15:29 -0600 Received: from DBDE73.ent.ti.com (dbde73.ent.ti.com [172.24.171.98]) by dbdlxv05.itg.ti.com (8.14.3/8.13.8) with ESMTP id rB4CFQ4k016414; Wed, 4 Dec 2013 17:45:27 +0530 Received: from DBDE04.ent.ti.com ([fe80::21ac:d9f:f810:c8e7]) by DBDE73.ent.ti.com ([fe80::bc19:dc43:44da:7415%27]) with mapi id 14.02.0342.003; Wed, 4 Dec 2013 20:15:25 +0800 From: "Gupta, Pekon" To: Stefan Roese , Nikita Kiryanov Thread-Topic: Fwd: [PATCH v4] arm: omap3: Add SPL support to cm_t35 Thread-Index: AQHO8OVgkoBJElLC2Euvq1feVOqW0ZpD6kbg Date: Wed, 4 Dec 2013 12:15:25 +0000 Message-ID: <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> In-Reply-To: <529F1428.7050804@denx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.170.142] MIME-Version: 1.0 Cc: "Rini, Tom" , U-Boot-Users Subject: Re: [U-Boot] Fwd: [PATCH v4] arm: omap3: Add SPL support to cm_t35 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: u-boot-bounces@lists.denx.de Errors-To: u-boot-bounces@lists.denx.de Hi Stefan, >From: Stefan Roese [mailto:sr@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. 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 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;