From patchwork Wed Jul 6 17:04:41 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Helmut Raiger X-Patchwork-Id: 103538 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 E2CACB6F6B for ; Thu, 7 Jul 2011 03:05:12 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id C5718280B2; Wed, 6 Jul 2011 19:05:09 +0200 (CEST) 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 ac24hN58wjvd; Wed, 6 Jul 2011 19:05:09 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 5FC332809A; Wed, 6 Jul 2011 19:05:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 353462809A for ; Wed, 6 Jul 2011 19:05:05 +0200 (CEST) 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 f6vWlmgjN4xV for ; Wed, 6 Jul 2011 19:05:04 +0200 (CEST) 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 mx.inode.at (mx01.lb01.inode.at [62.99.145.1]) by theia.denx.de (Postfix) with ESMTPS id 0C9F628081 for ; Wed, 6 Jul 2011 19:05:02 +0200 (CEST) Received: from [83.64.51.210] (port=6740 helo=gateway1.hale) by smartmx-01.inode.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QeVX3-0005hv-W7; Wed, 06 Jul 2011 19:05:02 +0200 Received: from mail1.hale.at (mail2.hale [192.168.100.12]) by gateway1.hale (8.13.8/8.13.7) with ESMTP id p66H4uvR020886; Wed, 6 Jul 2011 19:04:57 +0200 Received: from uni24.HALE ([192.168.100.40]) by hale.at with MailEnable ESMTP; Wed, 6 Jul 2011 19:04:52 +0200 From: helmut.raiger@hale.at To: u-boot@lists.denx.de Date: Wed, 6 Jul 2011 19:04:41 +0200 Message-Id: <1309971881-3797-1-git-send-email-helmut.raiger@hale.at> X-Mailer: git-send-email 1.7.4.4 MIME-Version: 1.0 X-HALE-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: p66H4uvR020886 X-HALE-MailScanner: Found to be clean X-HALE-MailScanner-From: helmut.raiger@hale.at MailScanner-NULL-Check: 1310576697.55186@sJI54CyG8+RKo6xvGTVVPA Cc: scottwood@freescale.com Subject: [U-Boot] [PATCH] mxc_nand: fix a problem writing more than 32MB X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.9 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 From: Helmut Raiger When writing 0x4000 to the unlockend_blkaddr register, large writes to a 2k page NAND sometimes fail. The current kernel driver writes 0xFFFF to this register for V2 of the nand controller. However on an i.MX31 this also fixes writes larger than 32MB. The datasheet is very unspecific, but (0x4000=16384)*2000 roughly fits the limits we're encountering with NAND writes. This problem might be NAND chip specific. Signed-off-by: Helmut Raiger --- drivers/mtd/nand/mxc_nand.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c index 78e07cc..35e89a0 100644 --- a/drivers/mtd/nand/mxc_nand.c +++ b/drivers/mtd/nand/mxc_nand.c @@ -1371,7 +1371,18 @@ int board_nand_init(struct nand_chip *this) /* Blocks to be unlocked */ writew(0x0, &host->regs->nfc_unlockstart_blkaddr); - writew(0x4000, &host->regs->nfc_unlockend_blkaddr); + /* Originally (Freescale LTIB 2.6.21) 0x4000 was written to the + * unlockend_blkaddr, but the magic 0x4000 does not always work + * when writing more than some 32 megabytes (on 2k page nands) + * However 0xFFFF doesn't seem to have this kind + * of limitation (tried it back and forth several times). + * The linux kernel driver sets this to 0xFFFF for the v2 controller + * only, but probably this was not tested there for v1. + * The very same limitation seems to apply to this kernel driver. + * This might be NAND chip specific and the i.MX31 datasheet is + * extremely vague about the semantics of this register. + */ + writew(0xFFFF, &host->regs->nfc_unlockend_blkaddr); /* Unlock Block Command for given address range */ writew(0x4, &host->regs->nfc_wrprot);