Received: by 10.223.185.116 with SMTP id b49csp8323375wrg; Thu, 1 Mar 2018 22:59:01 -0800 (PST) X-Google-Smtp-Source: AG47ELt+vWUFrdPM4dRIWQTgH6oN6nUtd4zkPigSgiagFOcuPXETFhpFhSjXs+H6w6GvANEca2PO X-Received: by 10.98.253.17 with SMTP id p17mr4700123pfh.105.1519973941035; Thu, 01 Mar 2018 22:59:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519973940; cv=none; d=google.com; s=arc-20160816; b=hl43LZ94teosgjObUIYtnb4kvHSgdaQHzpqS5C/284Jt6zwXzHjP/q+iHEKEdGTZwe vO9C20/NEXwZQfKZkJ9ANsPrQ7MzmvjzfWo50/LjYcokV3I5NJMW7iKwBd0ntF3wZLE7 G5kkecVXT/m8hd6RZfxTWfz4ZvUD/rIF2UWI8T5fnehtN/YLhq5jD2oHobNSnsbSkxEh efxsQG9b7xMhomDOZ6Vk2kend2r5Cojj4Plu9Bmm6At9RX3q008YgI0fe5Tr9hBjL9oL m7lYP3g0Sy11QCtwuopMWoUpOQYMf+xRsljTosvrEz6FXp2BwlX/6Qt15n867zb351nX b0Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:mime-version:dkim-signature :arc-authentication-results; bh=DruaklywrcYEkFz1WAunObcORXhT80lxE2SB2oz5IdY=; b=KpCiZL9+Gr9F0vJaQaAahGhLcEM6XvqPeZZ5/L1xCEw+K2noz0gkM8egba+M2kKL/X pQYZ3H6Czw2k1zC+egFyTVzOk2mdb92fqaQDJai67A2Qo5PrxWY7ja/BHAN2O76EpoYa khEoQx0qwdaiYw9sHoQBfhxWH6p7WLli/2lOioGD78cuWW0hkGI8Znm73e+ebkQ5uvKi CYw7EbjWzyRkrHizDvKqhI7Y4tvXuMCiQ4ID7bgU9VFFtKNeCRbrT8stEvBKaE6FiN/Z 1wcRczj9OYErbOb0Xe07w/tk6iTwCEEAcIWNpdVSgyI5E3j+A3GSLa6w+IVlP5LNkFIZ t40w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=D2+SsrPF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 65-v6si4354436plb.635.2018.03.01.22.58.46; Thu, 01 Mar 2018 22:59:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=D2+SsrPF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936076AbeCBG5b (ORCPT + 99 others); Fri, 2 Mar 2018 01:57:31 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:53229 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935863AbeCBG53 (ORCPT ); Fri, 2 Mar 2018 01:57:29 -0500 Received: by mail-wm0-f46.google.com with SMTP id t3so1166468wmc.2 for ; Thu, 01 Mar 2018 22:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=DruaklywrcYEkFz1WAunObcORXhT80lxE2SB2oz5IdY=; b=D2+SsrPFnR3k9mskm986z/poYFtoLQA2qkERmlwfkkqHXPRCMMvA4zTzi/hNRz3FwH F1tTq1xkFb/vuo/2XKfYe+Rpf1ssiw6JdypB1R49ESUBzfXu9EXAl0weG4iCkX1FmeB1 IblOlilxuFBE0sKz69fpK7MmCXxQx8tOXFC5hFsYELdH+5h7JKbROWABJSAuhClkBZhd ZUi8YSrv3bZOhzneFEFpbXLJWnQjdghq9UJJVIUECgKM1o7NQP/hcNv2t0HOrDjypKCB pumqQAxh+wD+fVo+p8R0njxIbzYn9emPki+BGBYgI/AuM8xMPfazfUXtF2xxJokdk+gF O/gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=DruaklywrcYEkFz1WAunObcORXhT80lxE2SB2oz5IdY=; b=XNc4B/u/yuJWB+zfPq95g37uKP6kZISqhvZof1cswcWdL9+YuANDTtti5xNOy4Af4A MMdLMz1mpvSW+5xoK46N+XLUAyhJCD6ZFp2MCk5FOh77QP2Om39lzRgXP53Z9JuY0Urb iHqOTn580lyzZLjxW663gnBBTCGi3q5JdqseOQ4VDI4+95cBF83dMlwPCJRZ6ENbGNcE 7Tx751wJ/cvJ4V+ZXPgsW9G1p6d4hqTnMeaWecmVT5qz/hY9y2WeRGWzx89oBwZ/4N2q bcwEZhOvlxrdKljsMbJyIbqi6fBliPUMgA4hsZbryJyihe2u/tHaKHfB+Kgmf9Kn1Xw9 AJPg== X-Gm-Message-State: APf1xPCdHWoLtAnEr3uPFfFZYilcV7hrcMYztL1LQgqJyiRKqIV7svmc gChNN3q+lrXGhmNs9VUh2YUjcDnma6E89nqgsHkW0REN X-Received: by 10.80.219.14 with SMTP id o14mr5689530edk.76.1519973847878; Thu, 01 Mar 2018 22:57:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.168.230 with HTTP; Thu, 1 Mar 2018 22:57:27 -0800 (PST) From: Maxim Uvarov Date: Fri, 2 Mar 2018 09:57:27 +0300 Message-ID: Subject: fsl,ifc + MT29F64G08CBAAAWP To: kernel list Cc: boris.brezillon@free-electrons.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, I'm trying to make work NAND MT29F64G08CBAAAWP with fsl IFC driver. And that seems trickly or I'm missing some fundamental thing. From MT29F64G08CBAAAWP it's said: Organization Page =E2=80=93 Page size x8: 8640 bytes (8192 + 448 bytes) =E2=80=93 Block size: 256 pages (2048K + 112K bytes) =E2=80=93 Plane size: 2 planes x 2048 blocks per plane =E2=80=93 Device size: 64Gb: 4096 blocks; 128Gb: 8192 blocks; 256Gb: 16,384 blocks; 512Gb: 32,786 blocks - Minimum required ECC 24-bit ECC per 1080 bytes of data (BCH algo for ECC) And it looks like drivers/mtd/nand/fsl_ifc_nand.c works well only with 512K blocks. So the question is - should I set up IFC driver absolutely the same as NAND chip spec says? Or it can work with smaller blocks? fsl_ifc_chip_init() csor =3D 0x9518c300 csor_ext 0x100000 fsl_ifc_chip_init() csor pgs =3D 0x180000 fsl_ifc_chip_init() CSOR_NAND_ECC_DEC_EN 1, CSOR_NAND_ECC_ENC_EN 1 fsl_ifc_chip_init() csor CSOR_NAND_ECC_MODE 268435456 fsl_ifc_chip_init() NAND_BUSWIDTH_16 0 nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x88 nand: Micron MT29F64G08CBAAAWP nand: 8192 MiB, MLC, erase size: 2048 KiB, page size: 8192, OOB size: 448 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->numchips =3D 1 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->chipsize =3D 8589= 934592 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->pagemask =3D f= ffff fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->chip_delay =3D 20= 0 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->badblockpos =3D 0 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->chip_shift =3D 33 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->page_shift =3D 13 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->phys_erase_shift = =3D 21 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->ecc.mode =3D 2 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->ecc.steps =3D 0 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->ecc.bytes =3D 16 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: nand->ecc.total =3D 0 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: mtd->ooblayout =3D (ptr= val) fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: mtd->flags =3D 00000000 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: mtd->size =3D 858993459= 2 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: mtd->erasesize =3D 2097= 152 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: mtd->writesize =3D 8192 fsl,ifc-nand 60000000.nand: fsl_ifc_chip_init_tail: mtd->oobsize =3D 448 nand: WARNING: 60000000.flash: the ECC used on your system is too weak compared to the one required by the NAND chip 1 ofpart partitions found on MTD device 60000000.flash Creating 1 MTD partitions on "60000000.flash": 0x000000000000-0x000040000000 : "rootfs" Issue is that on mtd_test I get I/O errors. The same as ubu_attach. ubi_format looks like pass first cycle but can not place bad blocks. Should this NAND chip work with IFC or there is some limitation? --=20 Best regards, Maxim Uvarov