| Message ID | 20130831025344.GA9971@gmail.com |
|---|---|
| State | New, archived |
| Headers | show |
On 08/31/2013 04:53 AM, Huang Shijie wrote: > On Fri, Aug 30, 2013 at 04:24:53PM +0200, Hector Palacios wrote: >> >Dear Huang, >> > >> >On 08/30/2013 11:55 AM, Huang Shijie wrote: >>> > >于 2013年08月30日 17:15, Hector Palacios 写道: >>>> > >>Hello, >>>> > >> >>>> > >>Working on my custom platform based on i.MX28 (and also with the >>>> > >>MX28EVK) I checked that I cannot mount JFFS2 nand partitions because >>>> > >>I'm getting this error: >>>> > >> >>>> > >>jffs2: inconsistent device description >>>> > >> >>>> > >>which seems to have to do with the OOB area of the NAND. >>>> > >>I saw patchset [1] from Huang Shijie which seems to be related to the >>>> > >>issue. I just wanted to confirm if other people has the same problem >>>> > >>and if the patchset really aims to solve this, or mine is a different >>>> > >>issue. >>>> > >> >>> > >yes, this patch set aims to solve this. >>> > > >>> > >You can try the SLC on the imx28. >>> > > >>> > >I only tested the SLC On the imx6q. >> > >> >I applied the patchset but I still get the same error when trying to >> >mount a JFFS2 filesystem. My nand is: >> > >> >[ 0.819654] ONFI param page 0 valid >> >[ 0.823179] ONFI flash detected >> >[ 0.826344] NAND device: Manufacturer ID: 0x2c,Chip ID: 0xaa (Micron MT29F2G08ABBEAH4) >> >[ 0.834455] NAND device: 256MiB, SLC, page size: 2048, OOB size: 64 >> > > Could you print out the spare bytes of the oob area? > > --- > drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c > index cc0306b..5461189 100644 > --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c > +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c > @@ -217,6 +217,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data *this) > if (geo->page_size < mtd->writesize + mtd->oobsize) { > of->offset = geo->page_size - mtd->writesize; > of->length = mtd->oobsize - of->offset; > + printk("[ %s ] %d, %d\n", __func__, of->offset, of->length); > } > > geo->payload_size = mtd->writesize; Sorry, what repo/branch did you base your original patchset on? The patchset did not apply correctly and this one you sent won't apply either because the function set_geometry_by_ecc_info() does not exist. Instead, it is called common_nfc_set_geometry(). I'm using a v3.10 kernel but this driver has not changed since then (at least in the vanilla kernel). I took a dump in U-Boot of the first sector of the JFFS2 partition, in case it helps: Page 07c00000 dump: e0 ff ff ff ff ff ff ff ff ff 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 00 00 00 00 02 00 00 00 e9 07 98 4f 03 04 00 00 99 f9 4e ee ff 83 66 55 62 69 6e ff 85 19 02 e0 44 00 00 00 1d fb f7 98 02 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0 3a 0f 4f 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 01 00 00 00 03 00 00 00 e9 07 98 4f 03 04 00 00 67 24 83 db 17 28 32 ee 64 65 76 ff 85 19 02 e0 44 00 00 00 1d fb f7 98 03 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6c d6 be 72 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 02 00 00 00 04 00 00 00 e9 07 98 4f 03 04 00 00 1a 79 d3 86 db 85 f4 d1 65 74 63 ff 85 19 02 e0 44 00 00 00 1d fb f7 98 04 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 50 ab c2 85 19 01 e0 2c 00 00 00 5f 56 f1 e0 01 00 00 00 03 00 00 00 05 00 00 00 e9 07 98 4f 04 04 00 00 5d 9c c9 2e cc d3 92 50 68 6f 6d 65 85 19 02 e0 44 00 00 00 1d fb f7 98 05 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a4 bc 1a ff 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 04 00 00 00 06 00 00 00 e9 07 98 4f 03 04 00 00 61 8e 79 39 de e2 4e 56 6c 69 62 ff 85 19 02 e0 44 00 00 00 1d fb f7 98 06 00 00 00 01 00 00 00 4e 8f 5f dd be 9a 44 2a 69 14 9a f9 70 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0 89 c8 b9 85 19 01 e0 2d 00 00 00 3a 31 4d 58 01 00 00 00 05 00 00 00 07 00 00 00 e9 07 98 4f 05 0a 00 00 49 21 41 23 11 56 0e ac 6d 65 64 69 61 ff ff ff 85 19 02 e0 4e 00 00 00 79 1b 4a f7 07 00 00 00 01 00 00 00 ff a1 00 00 00 00 00 00 0a 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 0a 00 00 00 0a 00 00 00 00 00 00 00 37 4e 6b ee 40 15 33 ba 2f 74 6d 70 2f 6d 65 64 69 61 ff ff 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 06 00 00 00 08 00 00 00 e9 07 98 4f 03 0a 00 00 16 55 76 5d 7f ab 19 ec 6d 6e 74 ff 85 19 02 e0 4c 00 00 00 f2 d3 43 5d 08 00 00 00 01 00 00 00 ff a1 00 00 00 00 00 00 08 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 08 00 00 00 08 00 00 00 00 00 00 00 9e 6c 81 61 02 67 03 aa 2f 74 6d 70 2f 6d 6e 74 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 07 00 00 00 09 00 00 00 e9 07 98 4f 03 04 00 00 e2 a5 25 62 8d 0a e2 b8 6e 66 73 ff 85 19 02 e0 44 00 00 00 1d fb f7 98 09 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 75 6f 23 3f 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 08 00 00 00 0a 00 00 00 e9 07 98 4f 03 04 00 00 28 10 51 9b ce 40 dc 3b 6f 70 74 ff 85 19 02 e0 44 00 00 00 1d fb f7 98 0a 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 95 88 e4 f6 31 f1 40 28 74 8d 60 34 21 00 00 00 00 11 5a f1 79 85 19 01 e0 2c 00 00 00 5f 56 f1 e0 01 00 00 00 09 00 00 00 0b 00 00 00 e9 07 98 4f 04 04 00 00 6f f5 4b 33 28 5b 94 0a 70 72 6f 63 85 19 02 e0 44 00 00 00 1d fb f7 98 0b 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cd b6 40 44 85 19 01 e0 2c 00 00 00 5f 56 f1 e0 01 00 00 00 0a 00 00 00 0c 00 00 00 e9 07 98 4f 04 04 00 00 12 a8 1b 6e 47 26 b0 37 72 6f 6f 74 85 19 02 e0 44 00 00 00 1d fb f7 98 0c 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d9 30 55 f4 85 19 01 e0 2c 00 00 00 5f 56 f1 e0 01 00 00 00 0b 00 00 00 0d 00 00 00 e9 07 98 4f 04 04 00 00 ec 75 d6 5b 8d 8c ec 2c 73 62 69 6e 85 19 02 e0 44 00 00 00 1d fb f7 98 0d 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 dc e4 c9 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 0c 00 00 00 0e 00 00 00 e9 07 98 4f 03 04 00 00 d0 67 66 4c 30 34 46 61 73 79 73 ff 85 19 02 e0 44 00 00 00 1d fb f7 98 0e 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 61 e9 36 8f 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 0d 00 00 00 0f 00 00 00 e9 07 98 4f 03 04 00 00 2e ba ab 79 5a a4 ae d3 74 6d 70 ff 85 19 02 e0 44 00 00 00 1d fb f7 98 db 2f 59 39 36 e7 c5 d4 f2 38 50 52 52 0f 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bd 05 87 b2 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 0e 00 00 00 10 00 00 00 e9 07 98 4f 03 04 00 00 51 7c ef 2e 9e 90 23 e8 75 73 72 ff 85 19 02 e0 44 00 00 00 1d fb f7 98 10 00 00 00 01 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4a 22 90 59 85 19 01 e0 2b 00 00 00 e6 6e 26 7d 01 00 00 00 0f 00 00 00 11 00 00 00 e9 07 98 4f 03 0a 00 00 a5 8c bc 11 14 5e 91 92 76 61 72 ff 85 19 02 e0 4c 00 00 00 f2 d3 43 5d 11 00 00 00 01 00 00 00 ff a1 00 00 00 00 00 00 08 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 08 00 00 00 08 00 00 00 00 00 00 00 f5 99 09 1f 3d 2a b0 cc 2f 74 6d 70 2f 76 61 72 85 19 01 e0 30 00 00 00 78 be 3e fa 02 00 00 00 10 00 00 00 12 00 00 00 e9 07 98 4f 08 0a 00 00 3a cd 47 76 47 36 3f 5b 61 64 64 67 72 6f 75 70 85 19 02 e0 4b 00 00 00 4b eb 94 c0 12 00 00 00 01 00 00 00 ff a1 00 00 00 00 00 00 07 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 07 00 00 00 07 00 00 00 00 00 00 00 9f 25 6b 18 45 b4 57 7a 62 75 73 79 62 6f 78 ff 85 19 01 e0 2f 00 00 00 b1 f9 44 f2 02 00 00 00 11 00 00 00 13 00 00 00 e9 07 98 4f 07 0a 00 00 92 00 e9 1b c5 d2 c1 7e 61 64 64 75 73 65 72 ff 85 19 02 OOB: ff 4b 00 00 00 4b eb 94 c0 13 00 00 00 01 00 00 00 ff a1 00 00 00 00 00 00 07 00 00 00 e9 07 98 4f e9 07 98 4f e9 07 98 4f 00 00 00 00 07 00 00 00 d6 88 4e 30 17 e5 05 72 4a c6 25 4e 8e 00 00 Best regards, -- Hector Palacios
Dear Huang, On 08/31/2013 05:34 AM, Huang Shijie wrote: > On Fri, Aug 30, 2013 at 05:23:34PM +0200, Hector Palacios wrote: >> On 08/31/2013 04:53 AM, Huang Shijie wrote: >>> On Fri, Aug 30, 2013 at 04:24:53PM +0200, Hector Palacios wrote: >> Sorry, what repo/branch did you base your original patchset on? The >> patchset did not apply correctly and this one you sent won't apply >> either because the function set_geometry_by_ecc_info() does not >> exist. Instead, it is called common_nfc_set_geometry(). I'm using a >> v3.10 kernel but this driver has not changed since then (at least in >> the vanilla kernel). > please apply this patch set with the l2-mtd tree or the linux-next. Ok I merged the linux-next MTD patches. This is what I get from the printk: [ 0.841333] [ set_geometry_by_ecc_info ] 36, 28 The partition now partially mounts (I can see a few of the folders and files) but I get thousands of errors like these: [ 118.210985] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC error [ 118.255424] jffs2: mtd->read(0x1ff20 bytes from 0xe0) returned ECC error [ 118.255561] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000001ec: Read 0x00000000, calculated 0xa587e8ba [ 118.255602] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000234: 0x1cf7 instead [ 118.255628] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000238: 0x0011 instead [ 118.255654] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000240: 0xd266 instead [ 118.255680] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000250: 0x21f8 instead [ 118.255704] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000258: 0x5e99 instead [ 118.255728] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000025c: 0x64ee instead [ 118.255752] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000260: 0xf626 instead [ 118.255776] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000264: 0x0021 instead [ 118.255801] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000026c: 0x8f7f instead [ 118.255826] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000278: 0x0004 instead [ 118.255843] jffs2: Further such events for this erase block will not be printed [ 118.265711] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0000c098: Read 0x85aaca2a, calculated 0xe4eba16f [ 118.272740] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000189ec: Read 0x3f000000, calculated 0xbe2aa989 [ 118.274823] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0001c9c8: Read 0xd4600000, calculated 0xa1dc0043 [ 118.278445] jffs2: mtd->read(0xde8 bytes from 0x1f218) returned ECC error [ 118.278503] jffs2: Empty flash at 0x0001f214 ends at 0x0001f400 [ 118.279858] jffs2: mtd->read(0xbec bytes from 0x1f414) returned ECC error [ 118.279904] jffs2: Empty flash at 0x0001f410 ends at 0x0001f604 [ 118.281199] jffs2: mtd->read(0x9e8 bytes from 0x1f618) returned ECC error Best regards, -- Hector Palacios
Hi Hector, On Fri, Aug 30, 2013 at 1:31 PM, Hector Palacios <hector.palacios@digi.com> wrote: > Ok I merged the linux-next MTD patches. > This is what I get from the printk: > > [ 0.841333] [ set_geometry_by_ecc_info ] 36, 28 > > The partition now partially mounts (I can see a few of the folders and > files) but I get thousands of errors like these: > > [ 118.210985] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC error > [ 118.255424] jffs2: mtd->read(0x1ff20 bytes from 0xe0) returned ECC error > [ 118.255561] jffs2: jffs2_scan_inode_node(): CRC failed on node at > 0x000001ec: Read 0x00000000, calculated 0xa587e8ba > [ 118.255602] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not > found at 0x00000234: 0x1cf7 instead This error is most likely because you generated a jffs2 rootfs with a eraseblock size that does not match the one of your NAND device. Try generating a new rootfs with the correct eraseblock size. Regards, Fabio Estevam
Hi Fabio, On 08/30/2013 06:37 PM, Fabio Estevam wrote: > Hi Hector, > > On Fri, Aug 30, 2013 at 1:31 PM, Hector Palacios > <hector.palacios@digi.com> wrote: >> Ok I merged the linux-next MTD patches. >> This is what I get from the printk: >> >> [ 0.841333] [ set_geometry_by_ecc_info ] 36, 28 >> >> The partition now partially mounts (I can see a few of the folders and >> files) but I get thousands of errors like these: >> >> [ 118.210985] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC error >> [ 118.255424] jffs2: mtd->read(0x1ff20 bytes from 0xe0) returned ECC error >> [ 118.255561] jffs2: jffs2_scan_inode_node(): CRC failed on node at >> 0x000001ec: Read 0x00000000, calculated 0xa587e8ba >> [ 118.255602] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not >> found at 0x00000234: 0x1cf7 instead > > This error is most likely because you generated a jffs2 rootfs with a > eraseblock size that does not match the one of your NAND device. No. I used 128k erase block that matches my NAND. I also checked that I can mount the jffs2 partition correctly using my v2.6.35 kernel, so the partition seems to be correctly written. Best regards, -- Hector Palacios
On Fri, Aug 30, 2013 at 05:23:34PM +0200, Hector Palacios wrote: > On 08/31/2013 04:53 AM, Huang Shijie wrote: > >On Fri, Aug 30, 2013 at 04:24:53PM +0200, Hector Palacios wrote: > Sorry, what repo/branch did you base your original patchset on? The > patchset did not apply correctly and this one you sent won't apply > either because the function set_geometry_by_ecc_info() does not > exist. Instead, it is called common_nfc_set_geometry(). I'm using a > v3.10 kernel but this driver has not changed since then (at least in > the vanilla kernel). please apply this patch set with the l2-mtd tree or the linux-next. thanks Huang Shijie
On Fri, Aug 30, 2013 at 06:41:58PM +0200, Hector Palacios wrote: > Hi Fabio, > > > > >On Fri, Aug 30, 2013 at 1:31 PM, Hector Palacios > ><hector.palacios@digi.com> wrote: > >>Ok I merged the linux-next MTD patches. > >>This is what I get from the printk: > >> > >>[ 0.841333] [ set_geometry_by_ecc_info ] 36, 28 ok, we have enough spare area to store the marker. I think this SLC should be okay with jffs2. > >> > >>The partition now partially mounts (I can see a few of the folders and > >>files) but I get thousands of errors like these: > >> > >>[ 118.210985] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC error > >>[ 118.255424] jffs2: mtd->read(0x1ff20 bytes from 0xe0) returned ECC error > >>[ 118.255561] jffs2: jffs2_scan_inode_node(): CRC failed on node at > >>0x000001ec: Read 0x00000000, calculated 0xa587e8ba > >>[ 118.255602] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not > >>found at 0x00000234: 0x1cf7 instead > > > >This error is most likely because you generated a jffs2 rootfs with a > >eraseblock size that does not match the one of your NAND device. > > No. I used 128k erase block that matches my NAND. I also checked > that I can mount the jffs2 partition correctly using my v2.6.35 > kernel, so the partition seems to be correctly written. > Please use following steps and try again: flash_eraseall /dev/mtdx mount -t jffs2 /dev/mtdblockx tmp thanks Huang Shijie
On Fri, Aug 30, 2013 at 06:41:58PM +0200, Hector Palacios wrote: > Hi Fabio, > > On 08/30/2013 06:37 PM, Fabio Estevam wrote: > >Hi Hector, > > > >On Fri, Aug 30, 2013 at 1:31 PM, Hector Palacios > ><hector.palacios@digi.com> wrote: > >>Ok I merged the linux-next MTD patches. > >>This is what I get from the printk: > >> > >>[ 0.841333] [ set_geometry_by_ecc_info ] 36, 28 > >> > >>The partition now partially mounts (I can see a few of the folders and > >>files) but I get thousands of errors like these: > >> > >>[ 118.210985] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC error > >>[ 118.255424] jffs2: mtd->read(0x1ff20 bytes from 0xe0) returned ECC error > >>[ 118.255561] jffs2: jffs2_scan_inode_node(): CRC failed on node at > >>0x000001ec: Read 0x00000000, calculated 0xa587e8ba > >>[ 118.255602] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not > >>found at 0x00000234: 0x1cf7 instead > > > >This error is most likely because you generated a jffs2 rootfs with a > >eraseblock size that does not match the one of your NAND device. > > No. I used 128k erase block that matches my NAND. I also checked > that I can mount the jffs2 partition correctly using my v2.6.35 > kernel, so the partition seems to be correctly written. > Keep the JFFS2_FS_DEBUG is 0. and test it again. thanks Huang Shijie
Dear Huang, On 08/31/2013 03:37 PM, Huang Shijie wrote: > On Fri, Aug 30, 2013 at 06:41:58PM +0200, Hector Palacios wrote: >> Hi Fabio, >> >>> >>> On Fri, Aug 30, 2013 at 1:31 PM, Hector Palacios >>> <hector.palacios@digi.com> wrote: >>>> Ok I merged the linux-next MTD patches. >>>> This is what I get from the printk: >>>> >>>> [ 0.841333] [ set_geometry_by_ecc_info ] 36, 28 > > ok, we have enough spare area to store the marker. > > I think this SLC should be okay with jffs2. > >>>> >>>> The partition now partially mounts (I can see a few of the folders and >>>> files) but I get thousands of errors like these: >>>> >>>> [ 118.210985] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC error >>>> [ 118.255424] jffs2: mtd->read(0x1ff20 bytes from 0xe0) returned ECC error >>>> [ 118.255561] jffs2: jffs2_scan_inode_node(): CRC failed on node at >>>> 0x000001ec: Read 0x00000000, calculated 0xa587e8ba >>>> [ 118.255602] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not >>>> found at 0x00000234: 0x1cf7 instead >>> >>> This error is most likely because you generated a jffs2 rootfs with a >>> eraseblock size that does not match the one of your NAND device. >> >> No. I used 128k erase block that matches my NAND. I also checked >> that I can mount the jffs2 partition correctly using my v2.6.35 >> kernel, so the partition seems to be correctly written. >> > > Please use following steps and try again: > flash_eraseall /dev/mtdx > mount -t jffs2 /dev/mtdblockx tmp What's the purpose of this? This works and doesn't output any error but it's mounting an erased partition. > Keep the JFFS2_FS_DEBUG is 0. > and test it again. JFFS2_FS_DEBUG is 0. The error messages above are printed nevertheless because they are pr_notice() calls, not jffs2_dbg(). Best regards, -- Hector Palacios
于 2013年09月02日 16:12, Hector Palacios 写道: >> I think this SLC should be okay with jffs2. >> >>>>> >>>>> The partition now partially mounts (I can see a few of the folders >>>>> and >>>>> files) but I get thousands of errors like these: >>>>> >>>>> [ 118.210985] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC >>>>> error >>>>> [ 118.255424] jffs2: mtd->read(0x1ff20 bytes from 0xe0) returned >>>>> ECC error >>>>> [ 118.255561] jffs2: jffs2_scan_inode_node(): CRC failed on node at >>>>> 0x000001ec: Read 0x00000000, calculated 0xa587e8ba >>>>> [ 118.255602] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 >>>>> not >>>>> found at 0x00000234: 0x1cf7 instead >>>> >>>> This error is most likely because you generated a jffs2 rootfs with a >>>> eraseblock size that does not match the one of your NAND device. >>> >>> No. I used 128k erase block that matches my NAND. I also checked >>> that I can mount the jffs2 partition correctly using my v2.6.35 >>> kernel, so the partition seems to be correctly written. >>> >> >> Please use following steps and try again: >> flash_eraseall /dev/mtdx >> mount -t jffs2 /dev/mtdblockx tmp > > What's the purpose of this? > This works and doesn't output any error but it's mounting an erased > partition. Please test the patch set after you have erased a partition. Since the ECC layout may be changed after applying this patch set. So You may meet some errors if you do not do so. > > > Keep the JFFS2_FS_DEBUG is 0. > > and test it again. > > JFFS2_FS_DEBUG is 0. The error messages above are printed nevertheless > because they are pr_notice() calls, not jffs2_dbg(). this is just a suggestiong. ignore this if you do not meet any error by following above steps. thanks Huang Shijie
Dear Huang, On 09/02/2013 10:24 AM, Huang Shijie wrote: > 于 2013年09月02日 16:12, Hector Palacios 写道: >>> I think this SLC should be okay with jffs2. >>> >>>>>> >>>>>> The partition now partially mounts (I can see a few of the folders >>>>>> and >>>>>> files) but I get thousands of errors like these: >>>>>> >>>>>> [ 118.210985] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC >>>>>> error >>>>>> [ 118.255424] jffs2: mtd->read(0x1ff20 bytes from 0xe0) returned >>>>>> ECC error >>>>>> [ 118.255561] jffs2: jffs2_scan_inode_node(): CRC failed on node at >>>>>> 0x000001ec: Read 0x00000000, calculated 0xa587e8ba >>>>>> [ 118.255602] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 >>>>>> not >>>>>> found at 0x00000234: 0x1cf7 instead >>>>> >>>>> This error is most likely because you generated a jffs2 rootfs with a >>>>> eraseblock size that does not match the one of your NAND device. >>>> >>>> No. I used 128k erase block that matches my NAND. I also checked >>>> that I can mount the jffs2 partition correctly using my v2.6.35 >>>> kernel, so the partition seems to be correctly written. >>>> >>> >>> Please use following steps and try again: >>> flash_eraseall /dev/mtdx >>> mount -t jffs2 /dev/mtdblockx tmp >> >> What's the purpose of this? >> This works and doesn't output any error but it's mounting an erased >> partition. > Please test the patch set after you have erased a partition. Since the > ECC layout may be changed after applying this > patch set. > > So You may meet some errors if you do not do so. I am writing the JFFS2 partition from my custom U-Boot. Do you mean that they way it writes it could not be compatible with what the new driver expects? That sounds really bad. How do you write the partition in Linux? Best regards, -- Hector Palacios
于 2013年09月02日 16:42, Hector Palacios 写道: > I am writing the JFFS2 partition from my custom U-Boot. Do you mean > that they way it writes it could not be compatible The mtd code(as well as the gpmi driver) has merge many patch to the kernel, BUT, the relative patches are not submitted to uboot maillist. So the code is not aligned between the uboot and the kernel. thanks Huang Shijie
Dear Huang, On 09/02/2013 10:50 AM, Huang Shijie wrote: > 于 2013年09月02日 16:42, Hector Palacios 写道: >> I am writing the JFFS2 partition from my custom U-Boot. Do you mean >> that they way it writes it could not be compatible with what the new >> driver expects? That sounds really bad. > > The mtd code(as well as the gpmi driver) has merge many patch to the kernel, > BUT, the relative patches are not submitted to uboot maillist. So the > code is not aligned between the > uboot and the kernel. Ok, I just rewrote the JFFS2 partition using the mtd-utils and now it mounts correctly and without any error. So does this mean that U-Boot is now unable to properly write a JFFS2 partition for it to be understood by the linux-next kernel? What is exactly the difference? Does it only affect Freescale NAND controllers? I'm including the U-Boot mailing list in CC. The complete thread for reference: http://patchwork.ozlabs.org/patch/271322/ Best regards, -- Hector Palacios
于 2013年09月02日 18:10, Hector Palacios 写道: > So does this mean that U-Boot is now unable to properly write a JFFS2 > partition for it to be understood by the linux-next For the gpmi nand controller, the uboot is not proper to write a jffs2 now. > kernel? What is exactly the difference? Does it only affect Freescale > NAND controllers? I think there are many difference. Just diff the nand_base.c, you can see there are many patches merged in the kernel's mtd code, but not exit in the uboot's mtd code. AFAIK, only the gpmi is affected now. thanks Huang Shijie
Dear Huang Shijie, > 于 2013年09月02日 18:10, Hector Palacios 写道: > > So does this mean that U-Boot is now unable to properly write a JFFS2 > > partition for it to be understood by the linux-next > > For the gpmi nand controller, the uboot is not proper to write a jffs2 now. > > > kernel? What is exactly the difference? Does it only affect Freescale > > NAND controllers? > > I think there are many difference. Just diff the nand_base.c, you can > see there are many patches merged in > the kernel's mtd code, but not exit in the uboot's mtd code. This makes not much sense to me. If what you claim is true, than JFFS2 in U-Boot and Linux would be incompatible for all MTD drivers. This would also mean that JFFS2 in Linux 3.7 is incompatible with Linux-next (since 3.7 was the last sync point between U-Boot and Linux MTD). Is that really the case? Best regards, Marek Vasut
于 2013年09月02日 19:32, Marek Vasut 写道: > This makes not much sense to me. If what you claim is true, than JFFS2 in U-Boot > and Linux would be incompatible for all MTD drivers. This would also mean that The jffs2 in uboot and linux is compatible now. But the mtd base code, such as nand_base.c /nand_bbt.c has changed. And the gpmi for kernel has be changed too. All these changes are not sync with the uboot yet. thanks Huang Shijie
Dear Huang Shijie, > 于 2013年09月02日 19:32, Marek Vasut 写道: > > This makes not much sense to me. If what you claim is true, than JFFS2 in > > U-Boot and Linux would be incompatible for all MTD drivers. This would > > also mean that > > The jffs2 in uboot and linux is compatible now. But the mtd base code, > such as nand_base.c /nand_bbt.c > has changed. Ok, based on this claim AND U-Boot being last synced with Linux 3.7, the obvious questions comes to mind. Is JFFS2 support in Linux 3.7 not compatible with JFFS2 in Linux -next? Is this true? Can I not mount JFFS2 partition under Linux-next that I could mount with Linux 3.7 and earlier? > And the gpmi for kernel has be changed too. > All these changes are not sync with the uboot yet. Best regards, Marek Vasut
于 2013年09月03日 19:53, Marek Vasut 写道: > questions comes to mind. Is JFFS2 support in Linux 3.7 not compatible with JFFS2 > in Linux -next? Is this true? Can I not mount JFFS2 partition under Linux-next The jffs2 does not changed since the linux 3.7. All the changes happened in the drivers and mtd code. The gpmi does not support the jffs2 all the time. Only apply the slc/mlc patch set, the gpmi can support the jffs2. So the jffs2 support is compatiable all the time. > that I could mount with Linux 3.7 and earlier? I think the mount can be succeeded. thanks Huang Shijie
Dear Huang Shijie, > 于 2013年09月03日 19:53, Marek Vasut 写道: > > questions comes to mind. Is JFFS2 support in Linux 3.7 not compatible > > with JFFS2 in Linux -next? Is this true? Can I not mount JFFS2 partition > > under Linux-next > > The jffs2 does not changed since the linux 3.7. > All the changes happened in the drivers and mtd code. OK, JFFS2 aside then, let's focus on MTD core code. > The gpmi does not support the jffs2 all the time. Only apply the slc/mlc > patch set, > the gpmi can support the jffs2. How come hector was then able to write his JFFS2 partition ? > So the jffs2 support is compatiable all the time. Is the old Freescale 2.6.35 GPMI NAND format compatible with the one after applying this patchset? > > that I could mount with Linux 3.7 and earlier? > > I think the mount can be succeeded. Ok, does that mean that we need this patchset in U-Boot in order to properly write JFFS2 onto GPMI NAND there? Is that the message you wanted to relay to us? Best regards, Marek Vasut
Dear Huang Shijie, > On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: > > Dear Huang Shijie, > > How come hector was then able to write his JFFS2 partition ? > > If he uses the gpmi, he should not write the JFFS2, since the gpmi > does not support the jffs2. He will get the failure in the end. Hector, can you comment on this? > > > So the jffs2 support is compatiable all the time. > > > > Is the old Freescale 2.6.35 GPMI NAND format compatible with the one > > after applying this patchset? > > Not compatible. > > This patch set is still underreview. So this patch breaks compatiblity with FSL kernel release? This needs fixing, otherwise it's impossible to do a drop-in replacement for the ancient FSL kernel. > > > > that I could mount with Linux 3.7 and earlier? > > > > > > I think the mount can be succeeded. > > > > Ok, does that mean that we need this patchset in U-Boot in order to > > properly write JFFS2 onto GPMI NAND there? Is that the message you > > wanted to relay to us? > > Besides this patchset, the u-boot needs more patches to sync with the > kernel mtd code. Such as the full-id features. Can you elaborate on this more? This is very vague, I would like to know what exactly is missing. Best regards, Marek Vasut
Dear Marek, On 09/04/2013 04:38 PM, Marek Vasut wrote: > Dear Huang Shijie, > >> On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: >>> Dear Huang Shijie, >>> How come hector was then able to write his JFFS2 partition ? >> >> If he uses the gpmi, he should not write the JFFS2, since the gpmi >> does not support the jffs2. He will get the failure in the end. > > Hector, can you comment on this? I don't think I'm following these comments. The facts are: 1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0) a) does not mount on kernel v3.10 b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from Huang (actually I didn't use linux-next but instead a v3.10 where I merged all the commits done to MTD in linux-next, which are a lot). 2) A JFFS2 filesystem image written with U-Boot v2013.01 a) mounts OK on old FSL kernel 2.6.35 b) does not mount on kernel v3.10 (neither on v3.8, I believe). c) does not mount on linux-next with the patchset [1] [1] http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html Marek, could you please confirm 2b on your side, just in case I'm doing anything wrong in my custom U-Boot? >>>> So the jffs2 support is compatiable all the time. >>> >>> Is the old Freescale 2.6.35 GPMI NAND format compatible with the one >>> after applying this patchset? >> >> Not compatible. >> >> This patch set is still underreview. > > So this patch breaks compatiblity with FSL kernel release? This needs fixing, > otherwise it's impossible to do a drop-in replacement for the ancient FSL > kernel. > >>>>> that I could mount with Linux 3.7 and earlier? >>>> >>>> I think the mount can be succeeded. >>> >>> Ok, does that mean that we need this patchset in U-Boot in order to >>> properly write JFFS2 onto GPMI NAND there? Is that the message you >>> wanted to relay to us? >> >> Besides this patchset, the u-boot needs more patches to sync with the >> kernel mtd code. Such as the full-id features. > > Can you elaborate on this more? This is very vague, I would like to know what > exactly is missing. Yes, please, we need more details. This seems to be related with how the MTD drivers (in Linux and in U-Boot) access the OOB area to store the JFFS2 cleanmarkers, right? The error I'm receiving from the kernel is at fs/jffs2/wbuf.c if (!oinfo || oinfo->oobavail == 0) { pr_err("inconsistent device description\n"); return -EINVAL; } Best regards, -- Hector Palacios
On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: > Dear Huang Shijie, > How come hector was then able to write his JFFS2 partition ? If he uses the gpmi, he should not write the JFFS2, since the gpmi does not support the jffs2. He will get the failure in the end. > > > So the jffs2 support is compatiable all the time. > > Is the old Freescale 2.6.35 GPMI NAND format compatible with the one after > applying this patchset? Not compatible. This patch set is still underreview. > > > > that I could mount with Linux 3.7 and earlier? > > > > I think the mount can be succeeded. > > Ok, does that mean that we need this patchset in U-Boot in order to properly > write JFFS2 onto GPMI NAND there? Is that the message you wanted to relay to us? Besides this patchset, the u-boot needs more patches to sync with the kernel mtd code. Such as the full-id features. thanks Huang Shijie
于 2013年09月04日 23:46, Hector Palacios 写道: > Dear Marek, > > On 09/04/2013 04:38 PM, Marek Vasut wrote: >> Dear Huang Shijie, >> >>> On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: >>>> Dear Huang Shijie, >>>> How come hector was then able to write his JFFS2 partition ? >>> >>> If he uses the gpmi, he should not write the JFFS2, since the gpmi >>> does not support the jffs2. He will get the failure in the end. >> >> Hector, can you comment on this? > > I don't think I'm following these comments. The facts are: > 1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0) > a) does not mount on kernel v3.10 > b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from > Huang > (actually I didn't use linux-next but instead a v3.10 where I merged > all the commits done to MTD in linux-next, which are a lot). > > 2) A JFFS2 filesystem image written with U-Boot v2013.01 > a) mounts OK on old FSL kernel 2.6.35 > b) does not mount on kernel v3.10 (neither on v3.8, I believe). > c) does not mount on linux-next with the patchset [1] The gpmi driver in FSL kernel 2.6.35 is different from the linux-next or linux v3.10. We have abandoned the old gpmi driver, and we use the same gpmi code in current FSL kernel. Since we swtich to the upstream gpmi code, and it could not support the jffs2, and that's why you mount always failed. > > [1] > http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html > > Marek, could you please confirm 2b on your side, just in case I'm > doing anything wrong in my custom U-Boot? > > >>>>> So the jffs2 support is compatiable all the time. >>>> >>>> Is the old Freescale 2.6.35 GPMI NAND format compatible with the one >>>> after applying this patchset? >>> >>> Not compatible. >>> >>> This patch set is still underreview. >> >> So this patch breaks compatiblity with FSL kernel release? This needs >> fixing, >> otherwise it's impossible to do a drop-in replacement for the ancient >> FSL >> kernel. >> >>>>>> that I could mount with Linux 3.7 and earlier? >>>>> >>>>> I think the mount can be succeeded. >>>> >>>> Ok, does that mean that we need this patchset in U-Boot in order to >>>> properly write JFFS2 onto GPMI NAND there? Is that the message you >>>> wanted to relay to us? >>> >>> Besides this patchset, the u-boot needs more patches to sync with the >>> kernel mtd code. Such as the full-id features. >> >> Can you elaborate on this more? This is very vague, I would like to >> know what >> exactly is missing. > 92a2645 mtd: add 4 Toshiba nand chips for the full-id case ec6e87e mtd: add the support to parse out the full-id nand type f22d5f6 mtd: add new fields to nand_flash_dev{} 2febcdf mtd: gpmi: set the BCH's geometry with the ecc info d1048aa mtd: add the ecc info for some full-id nand chips 5721934 mtd: parse out the ECC info for the full-id nand chips 2dc0bdd mtd: add ECC info for nand_flash_dev{} e2985fc mtd: replace the hardcode with the onfi_feature() 6dcbe0c mtd: get the ECC info from the Extended Parameter Page 5b40db6 mtd: add a helper to get the supported features for ONFI nand 5138a98 mtd: add data structures for Extended Parameter Page 10c86ba mtd: get the ECC info from the parameter page for ONFI nand 4cfeca2 mtd: add datasheet's ECC information to nand_chip{} > Yes, please, we need more details. This seems to be related with how > the MTD drivers (in Linux and in U-Boot) access the OOB area to store > the JFFS2 cleanmarkers, right? > > The error I'm receiving from the kernel is at fs/jffs2/wbuf.c > > if (!oinfo || oinfo->oobavail == 0) { > pr_err("inconsistent device description\n"); > return -EINVAL; > } Before apply the patches above, the gpmi will use all the oob, so "oinfo->oobavail == 0" becomes true. After apply the patches, the gpmi will not use all the oob for the ONFI SLC nand or the full-id nand, and it can supports the jffs2 when you apply the other SLC/MLC patchset. thanks Huang Shijie
Dear Hector Palacios, > Dear Marek, > > On 09/04/2013 04:38 PM, Marek Vasut wrote: > > Dear Huang Shijie, > > > >> On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: > >>> Dear Huang Shijie, > >>> How come hector was then able to write his JFFS2 partition ? > >> > >> If he uses the gpmi, he should not write the JFFS2, since the gpmi > >> does not support the jffs2. He will get the failure in the end. > > > > Hector, can you comment on this? > > I don't think I'm following these comments. The facts are: > 1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0) > a) does not mount on kernel v3.10 > b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from Huang > (actually I didn't use linux-next but instead a v3.10 where I merged all > the commits done to MTD in linux-next, which are a lot). > > 2) A JFFS2 filesystem image written with U-Boot v2013.01 > a) mounts OK on old FSL kernel 2.6.35 > b) does not mount on kernel v3.10 (neither on v3.8, I believe). > c) does not mount on linux-next with the patchset [1] > > [1] http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html > > Marek, could you please confirm 2b on your side, just in case I'm doing > anything wrong in my custom U-Boot? Sorry for the late reply. I cannot test it, since I don't have such a setup. I still believe it'd be worth figuring out what the heck is going on in here. There is obviously a bug which breaks compatibility and that must not happen. [...] Best regards, Marek Vasut
Dear Huang Shijie, > 于 2013年09月04日 23:46, Hector Palacios 写道: > > Dear Marek, > > > > On 09/04/2013 04:38 PM, Marek Vasut wrote: > >> Dear Huang Shijie, > >> > >>> On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: > >>>> Dear Huang Shijie, > >>>> How come hector was then able to write his JFFS2 partition ? > >>> > >>> If he uses the gpmi, he should not write the JFFS2, since the gpmi > >>> does not support the jffs2. He will get the failure in the end. > >> > >> Hector, can you comment on this? > > > > I don't think I'm following these comments. The facts are: > > 1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0) > > a) does not mount on kernel v3.10 > > b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from > > Huang > > (actually I didn't use linux-next but instead a v3.10 where I merged > > all the commits done to MTD in linux-next, which are a lot). > > > > 2) A JFFS2 filesystem image written with U-Boot v2013.01 > > a) mounts OK on old FSL kernel 2.6.35 > > b) does not mount on kernel v3.10 (neither on v3.8, I believe). > > c) does not mount on linux-next with the patchset [1] > > The gpmi driver in FSL kernel 2.6.35 is different from the linux-next or > linux v3.10. > > We have abandoned the old gpmi driver, and we use the same gpmi code in > current FSL kernel. > > Since we swtich to the upstream gpmi code, and it could not support the > jffs2, > > and that's why you mount always failed. With the patchset, mounting the jffs should work again, no? If mounting the jffs works with the patchset AND it only works with jffs written using the new driver, you will need to introduce soem compatibility option or something along that. > > [1] > > http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html > > > > Marek, could you please confirm 2b on your side, just in case I'm > > doing anything wrong in my custom U-Boot? > > > >>>>> So the jffs2 support is compatiable all the time. > >>>> > >>>> Is the old Freescale 2.6.35 GPMI NAND format compatible with the one > >>>> after applying this patchset? > >>> > >>> Not compatible. > >>> > >>> This patch set is still underreview. > >> > >> So this patch breaks compatiblity with FSL kernel release? This needs > >> fixing, > >> otherwise it's impossible to do a drop-in replacement for the ancient > >> FSL > >> kernel. > >> > >>>>>> that I could mount with Linux 3.7 and earlier? > >>>>> > >>>>> I think the mount can be succeeded. > >>>> > >>>> Ok, does that mean that we need this patchset in U-Boot in order to > >>>> properly write JFFS2 onto GPMI NAND there? Is that the message you > >>>> wanted to relay to us? > >>> > >>> Besides this patchset, the u-boot needs more patches to sync with the > >>> kernel mtd code. Such as the full-id features. > >> > >> Can you elaborate on this more? This is very vague, I would like to > >> know what > >> exactly is missing. > > 92a2645 mtd: add 4 Toshiba nand chips for the full-id case > ec6e87e mtd: add the support to parse out the full-id nand type Do these really have any impact? > f22d5f6 mtd: add new fields to nand_flash_dev{} > 2febcdf mtd: gpmi: set the BCH's geometry with the ecc info > d1048aa mtd: add the ecc info for some full-id nand chips > 5721934 mtd: parse out the ECC info for the full-id nand chips > 2dc0bdd mtd: add ECC info for nand_flash_dev{} > e2985fc mtd: replace the hardcode with the onfi_feature() > 6dcbe0c mtd: get the ECC info from the Extended Parameter Page > 5b40db6 mtd: add a helper to get the supported features for ONFI nand > 5138a98 mtd: add data structures for Extended Parameter Page > 10c86ba mtd: get the ECC info from the parameter page for ONFI nand > 4cfeca2 mtd: add datasheet's ECC information to nand_chip{} Hector, can you inspect those patches ? > > Yes, please, we need more details. This seems to be related with how > > the MTD drivers (in Linux and in U-Boot) access the OOB area to store > > the JFFS2 cleanmarkers, right? > > > > The error I'm receiving from the kernel is at fs/jffs2/wbuf.c > > > > if (!oinfo || oinfo->oobavail == 0) { > > pr_err("inconsistent device description\n"); > > return -EINVAL; > > } > > Before apply the patches above, the gpmi will use all the oob, so > "oinfo->oobavail == 0" becomes true. > > After apply the patches, the gpmi will not use all the oob for the ONFI > SLC nand or the full-id nand, > and it can supports the jffs2 when you apply the other SLC/MLC patchset. So the patches you listed above are not enough? Best regards, Marek Vasut
于 2013年09月15日 22:18, Marek Vasut 写道: > Dear Huang Shijie, > >> 于 2013年09月04日 23:46, Hector Palacios 写道: >>> Dear Marek, >>> >>> On 09/04/2013 04:38 PM, Marek Vasut wrote: >>>> Dear Huang Shijie, >>>> >>>>> On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: >>>>>> Dear Huang Shijie, >>>>>> How come hector was then able to write his JFFS2 partition ? >>>>> If he uses the gpmi, he should not write the JFFS2, since the gpmi >>>>> does not support the jffs2. He will get the failure in the end. >>>> Hector, can you comment on this? >>> I don't think I'm following these comments. The facts are: >>> 1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0) >>> a) does not mount on kernel v3.10 >>> b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from >>> Huang >>> (actually I didn't use linux-next but instead a v3.10 where I merged >>> all the commits done to MTD in linux-next, which are a lot). >>> >>> 2) A JFFS2 filesystem image written with U-Boot v2013.01 >>> a) mounts OK on old FSL kernel 2.6.35 >>> b) does not mount on kernel v3.10 (neither on v3.8, I believe). >>> c) does not mount on linux-next with the patchset [1] >> The gpmi driver in FSL kernel 2.6.35 is different from the linux-next or >> linux v3.10. >> >> We have abandoned the old gpmi driver, and we use the same gpmi code in >> current FSL kernel. >> >> Since we swtich to the upstream gpmi code, and it could not support the >> jffs2, >> >> and that's why you mount always failed. > With the patchset, mounting the jffs should work again, no? If mounting the jffs If the jffs2 image is written by the uboot, the mounting should not works. > works with the patchset AND it only works with jffs written using the new > driver, you will need to introduce soem compatibility option or something along > that. do you mean i should a new dt property for the jffs2 support ? >>> [1] >>> http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html >>> >>> Marek, could you please confirm 2b on your side, just in case I'm >>> doing anything wrong in my custom U-Boot? >>> >>>>>>> So the jffs2 support is compatiable all the time. >>>>>> Is the old Freescale 2.6.35 GPMI NAND format compatible with the one >>>>>> after applying this patchset? >>>>> Not compatible. >>>>> >>>>> This patch set is still underreview. >>>> So this patch breaks compatiblity with FSL kernel release? This needs >>>> fixing, >>>> otherwise it's impossible to do a drop-in replacement for the ancient >>>> FSL >>>> kernel. >>>> >>>>>>>> that I could mount with Linux 3.7 and earlier? >>>>>>> I think the mount can be succeeded. >>>>>> Ok, does that mean that we need this patchset in U-Boot in order to >>>>>> properly write JFFS2 onto GPMI NAND there? Is that the message you >>>>>> wanted to relay to us? >>>>> Besides this patchset, the u-boot needs more patches to sync with the >>>>> kernel mtd code. Such as the full-id features. >>>> Can you elaborate on this more? This is very vague, I would like to >>>> know what >>>> exactly is missing. >> 92a2645 mtd: add 4 Toshiba nand chips for the full-id case >> ec6e87e mtd: add the support to parse out the full-id nand type > Do these really have any impact? > yes. the full-id nand is not supported by the old mtd code. >> f22d5f6 mtd: add new fields to nand_flash_dev{} >> 2febcdf mtd: gpmi: set the BCH's geometry with the ecc info >> d1048aa mtd: add the ecc info for some full-id nand chips >> 5721934 mtd: parse out the ECC info for the full-id nand chips >> 2dc0bdd mtd: add ECC info for nand_flash_dev{} >> e2985fc mtd: replace the hardcode with the onfi_feature() >> 6dcbe0c mtd: get the ECC info from the Extended Parameter Page >> 5b40db6 mtd: add a helper to get the supported features for ONFI nand >> 5138a98 mtd: add data structures for Extended Parameter Page >> 10c86ba mtd: get the ECC info from the parameter page for ONFI nand >> 4cfeca2 mtd: add datasheet's ECC information to nand_chip{} > Hector, can you inspect those patches ? > >>> Yes, please, we need more details. This seems to be related with how >>> the MTD drivers (in Linux and in U-Boot) access the OOB area to store >>> the JFFS2 cleanmarkers, right? >>> >>> The error I'm receiving from the kernel is at fs/jffs2/wbuf.c >>> >>> if (!oinfo || oinfo->oobavail == 0) { >>> pr_err("inconsistent device description\n"); >>> return -EINVAL; >>> } >> Before apply the patches above, the gpmi will use all the oob, so >> "oinfo->oobavail == 0" becomes true. >> >> After apply the patches, the gpmi will not use all the oob for the ONFI >> SLC nand or the full-id nand, >> and it can supports the jffs2 when you apply the other SLC/MLC patchset. > So the patches you listed above are not enough? It should be enough. thanks Huang Shijie
Dear Huang Shijie, Sorry, I think I got lost in the discussion. I will pull out. btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm trying to backport patches from -next and apply the GPMI NAND patchset, without much luck yet. Best regards, Marek Vasut
Dear Marek Vasut, On 09/19/2013 06:07 PM, Marek Vasut wrote: > btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm > trying to backport patches from -next and apply the GPMI NAND patchset, without > much luck yet. If it helps, to make it work on v3.10 I had to apply lots of commits (listed in reverse order, from most recent to oldest): 53a9abf27213154d1ebaa54d111533f1e69d8ef3 mtd: mtd-abi: add a helper to detect the nand type 44aabd5fe3423f5b2071379bd55e708d523a1b4c mtd: add a helper to detect the nand type 2a2d49314b6a36eca80947ad021d01f7e6294291 mtd: add MTD_MLCNANDFLASH case for mtd_type_show() 576c9744f0f62d0b8d207d74b9066f00f4bdd347 jffs2: do not support the MLC nand 654b09629a50fd1680afcce46514e9ffc6723418 mtd: fix the wrong mtd->type for nand chip 95bc60491c394174cdbd1b24b0940fa61b6f2aec mtd: add more comment for MTD_NANDFLASH/MTD_MLCNANDFLASH b9032012d68cf881e48237336e79d783b69f2a1b mtd: gpmi: rewrite the gpmi_ecc_write_oob() to support the jffs2 2c92e6f5e6a61020443ec3dbb7d51c6a84170f36 mtd: print out the cell information for nand chip 01e1b2c398952ead5d8b3eb370dc7a31560e9c00 mtd: set the cell information for ONFI nand 2dcd73d5c96067342fafeb088cc08872f68558d5 mtd: nand: rename the cellinfo to bits_per_cell 40f5c3f65f9f2151ae5cdd9293af6d62f551d51a mtd: add a new field to mtd_info{} a0181739d881f3e973ebfbe29769f0d4f08b26a4 mtd: add ECC info for nand_flash_dev{} 247db5b42147d0b764c6096e1b55c7f01439b9a5 mtd: add a helper to get the supported features for ONFI nand 0db74df18a1dbd9814637ba891cc123f3b7a4bba mtd: add data structures for Extended Parameter Page f4ead19a666581c78a7f9d27379e4ee4850d38ae mtd: add datasheet's ECC information to nand_chip{} b47e2aa8f044092ea63a2b28d1ead0ff6bc54ac3 mtd: nand: remove NAND_BBT_SCANEMPTY 91eae06eb963ad7f5faf8f585f21d34921cb7830 mtd: nand: hide in-memory BBT implementation details 4b8c49529b49e84a9472e52ffa2b452b48779563 mtd: nand_base: Only use GET/SET FEATURES command on chips that support them. 8babb2385cfcd9ee24b62e2dd1577a1e05ef2f1f mtd: nand: fsmc: update of OF support 34b182c94acfc08e851af3500d8f3fa8b1d073e5 mtd: increase max OOB size to 744 b726168414d1ce3cff143e4bdc3f944459894388 mtd: nand: reword nand_chip bad block interface comments 36b46f044704df158078beaa368284fdc435f34a mtd: mpc5121_nfc: cleanup clock API use 5afbc047077a88c38181b9d4de6bea70a140b5a0 mtd cs553x_nand: use kzalloc() instead of memset 247f500f0903c084fa04f96e41aed049a3ec0709 mtd: atmel_nand: fix error return code in atmel_nand_probe() 573f505290ac60920d2e4d4c39323acb14b7b0c4 mtd: remove alauda driver 240ca8e6f0f5689bc34130c5843fc7df40fc994a mtd: nand: mxc_nand: mark 'const' properly fdd0ddf7fac3ae18b8cbaf64a60a3f9591e124ac mtd: r852: Staticize local symbols e979054e90b480bb62ac8ac2d69bbe13418f6514 mtd: nandsim: Staticize local symbols cfa8de169b47502e0ce8b30b9a79b615b68af6b1 mtd: MTD_NAND_DENALI should depend on HAS_DMA d322e0477e11fdd9bdec1040a7c8d4e14ec3e188 mtd: fsmc_nand: simplify platform_get_resource_byname/devm_ioremap_resource f09f9d2061572d858856085d57d2f580fb60db0d mtd: atmel_nand: pmecc: fix bug fail to correct bit error in 1024-bytes sector 8a7f3dbd96350bc1d3f012c14da682049eb89530 mtd: nand: fixup kerneldoc, rename parameter 69d75957804c0cc214b705fee8c618bcca6c1671 mtd: gpmi: remove the nand_scan() 6aa28d55ddaf7ce5e245f835bfd0871ef3db492c mtd: set ONFI nand's default hooks in nand_set_defaults() 3320916b8845e06d04cea7b492920829ce49ac0e mtd: set the ecc step size for master/slave mtd_info 8d6a288d8b950b08a150f96781d365f770669898 mtd: nand: silence some shift wrap warnings 38cd6478fb2b38b12525fbede22cf549e1581a3e mtd: simplify use of devm_ioremap_resource 7b900eb9f497da080c3a46a50fe33ffa14e093aa mtd: nand: Allow to build pxa3xx_nand on Orion platforms 2cd4ce5d72919da4a5eb48f63d50ccbb38d96b19 mtd: nand: pxa3xx: Allow devices with no dma resources 383b9edf4a14193c819cb5f1cf841206da064095 mtd: nand: pxa3xx: Add __maybe_unused keyword to enable_int() 4552440a0c279fac04e4a7216c36a537956a2acc mtd: nand: pxa3xx: Make dma code dependent on dma capable platforms 475e1ad93c4bc100ad8ed82013669f8569471a96 mtd: nand: pxa3xx: Move cached registers to info structure 8270cfd39ae136c10082287f612f825414a01950 mtd: nand: pxa3xx: Remove uneeded internal cmdset 234f82f9269e2a96c4b6f3802121d8e307d29580 mtd: nand: pxa3xx: Remove hardcoded mtd name afa5a8a3750f428fe4c9f9a5840dfddfe4f7d503 mtd: nand: pxa3xx: Add a local loop variable dc33d8fcfc245dab443ef1a5172864bb6d3d2c94 mtd: nand: pxa3xx: Use 'length override' in ONFI paramater page read 1b3334cf50d40eb1ef7f39d6e3396b30d5d085f0 mtd: nand: pxa3xx: Support command buffer #3 33275c59dab511acd0fbb988519bd8dba670b7ff mtd: nand: pxa3xx: Allow to set/clear the 'spare enable' field 08f509aac14a0c7120f2885ac543c9758b00a518 mtd: nand: pxa3xx: Handle ECC and DMA enable/disable properly 00187c3a76b6e3da79ef495ce2a6c68fe96ee0de mtd: nand: pxa3xx: Introduce 'marvell,armada370-nand' compatible string 58fd0eb5d7fa386ff2ef23490d69b8a7699ed85b mtd: nand: pxa3xx: Remove unneeded ifdef CONFIG_OF 3a60185cc775357153f52804f61d0a271a5f0696 fs: create file_readable() and file_writable() functions 35d0c403f8df90eb53f8b3d7058435a5971cf843 mtd: gpmi: set the BCH's geometry with the ecc info e9f731bd91a0b0de671f2c786152913d77aa37b3 mtd: add the ecc info for some full-id nand chips 2574dd936a6039a9e0c64e598e728384fc5d1fb5 mtd: parse out the ECC info for the full-id nand chips 7f9da59d3ce36590295543d4b59e0f8b7d68ca0d mtd: replace the hardcode with the onfi_feature() 26b275a4f4ed1191f1be7c4489f568c8604de641 mtd: get the ECC info from the Extended Parameter Page 77788a73eab5c6a8cbda30b8797a269c1f8e3480 mtd: get the ECC info from the parameter page for ONFI nand c8daf04b75e1cee55a81cc47c28daca921e8ce15 mtd: atmel_nand: move the sanity check to the beginning of pmecc_enable() 67f6dd67d69b9d018411a2e34b10a192edb2aeaf mtd: nand: use dev_get_platdata() 7120499942b95c88e8273bef557906e14742911f mtd: denali: use NAND_CI_CELLTYPE_MSK instead of hardcoded constant 6105c5fc8cbfab44c80fc2ff24d3de89edca8946 mtd: nand: gpmi-nand: use more sensible error codes at various places fbecc4c137f70f1d7d8f43de600f08242c75934b mtd: nand: gpmi-nand: janitorial cleanup: (commas after last element of struct initializ 77ba056a60d8ace805410002129036cff4bf5c52 mtd: atmel_nand: fix the warning when CONFIG_OF is not defined f889dd6aec3fd3041d650b3b4ba32a1f167836c1 mtd: nand: remove NAND_BBT_SCANEMPTY 01b5773bb02cc534a073272e45f2d75928aabbdb mtd: nand: hide in-memory BBT implementation details 3f61aa34c884cc1fa67f97d5a25772112b0147a8 mtd: nand: refactor chip->block_markbad interface d15973ed747ce28d129f0f08cbcf7248f83ce7b0 mtd: nand: eliminate cast d5ec22b16799f05f222ce949df9f7c7788c9a388 mtd: nand: remove multiplied-by-2 block logic ff4ef6b2faf909227c06b1c7494f9e9b009d0711 mtd: nand: add accessors, macros for in-memory BBT 572acb4aec443d9b07ca62dcd2e321aff64c2058 mtd: atmel_nand: enable Nand Flash Controller (NFC) write via sram 7fdd5e2555451c9646303f87001f33a2b180d3a5 mtd: atmel_nand: enable Nand Flash Controller (NFC) read data via sram f3c0fc1870a4ac21ebda77b69477e35ee2345fab mtd: atmel_nand: add Nand Flash Controller (NFC) support f9be6c059590d55b16000353bd25180fb3524060 mtd: atmel_nand: replace pmecc enable code with one function. 995979747c758d0618a5999b72e4e9645126996a mtd: atmel_nand: use devm_xxx gpio kzalloc, gpio and ioremap d8b351cb3f380345eeaa6de0911568ebd083f763 mtd: nandsim: remove unused ns->geom.oobshift 6250f5a5b534e8840eafb6773e1d1fe4aa337096 mtd: nandsim: remove unused code 414d34c448779edc1ea9517fc9f75cb740091fd2 mtd: nandsim: use NS_RAW_OFFSET() 32ed63c74fdc9c11b5a744f2d846d9ff3dc690c8 mtd: nandsim: simplify NS_RAW_OFFSET() 0361bb75b2d75efcd30ca79531862e6799e6e3a0 mtd: nandsim: use kasprintf() c50761be2b4c278247d4ef198d2120043cb96083 mtd: nandsim: convert pages_written[] to bitmap b0430eb26dbcff68528a48ad55865c25cb8e7dce mtd: nand: detect OOB size for Toshiba 24nm raw SLC af1f55ae90e1e8060318b1e16b9a2c1cb55c6956 mtd: atmel_nand: fix pmecc selction for ecc requirement typo d05debb658fd8ff72e570e04ea1950b6980f229d mtd: nand: fix NAND_BUSWIDTH_AUTO for x16 devices d8f855a6961028909032d617fb35bb440dd7ad33 mtd: diskonchip: remove unused entries in Kconfig 861ef3fb9819f5b3688836ff7e4c44180b9982df mtd: atmel_nand: don't use devm_pinctrl_get_select_default() in probe c7babfbc49aa6f903e66b93b88dd8736279df2c9 mtd: gpmi-nand: don't use devm_pinctrl_get_select_default() in probe 84c9313cacdbc8d8e7bfbca5e1f94569dfd94a5f mtd: nand: mxc_nand: Remove unneeded check for platform_get_resource() 7f62a0169b724684e4cf33ecb782134359271919 mtd: atmel_nand: using a stronger ECC is not dangerous b3be64643c39f91401e017d67182dd1089be1a14 mtd: nand: txx9ndfmc: remove unnecessary platform_set_drvdata() 3d74b88ef09bcf3538dad9e16c35bd4133897fed mtd: nand: sharpsl: remove unnecessary platform_set_drvdata() 62f78268fe22bd4116715dc3a0a063789786e532 mtd: nand: s3c2410: remove unnecessary platform_set_drvdata() f11ce2b3680b5491973b5592195c4a3e49292191 mtd: nand: pxa3xx_nand: remove unnecessary platform_set_drvdata() ccc3fab23551b0f737066f1c3d15105f768779f5 mtd: nand: plat_nand: remove unnecessary platform_set_drvdata() 3e6c8f5e62d48ea2a97e60a5d57a2e4df2b8c8bd mtd: nand: orion_nand: remove unnecessary platform_set_drvdata() 284ec293b80ce08ceb2677bbd15cfda2fd4d9794 mtd: nand: omap2: remove unnecessary platform_set_drvdata() 9315d116a80429c9ce2f9378079b6a829b523c10 mtd: nand: nuc900_nand: remove unnecessary platform_set_drvdata() 1a35df39fb4f948f4fbc7908033ec9c122567166 mtd: nand: mxc_nand: remove unnecessary platform_set_drvdata() da4ed680a5530367f672cdfaf1860a71a7c8185e mtd: nand: lpc32xx: remove unnecessary platform_set_drvdata() 294824698f8267788a381928fe1818f1d695e258 mtd: nand: jz4740_nand: remove unnecessary platform_set_drvdata() 5e72ee56f9113d60cabb4f8adc2c1fa4f15f82a9 mtd: nand: gpmi-nand: remove unnecessary platform_set_drvdata() 63d5c5167c38967ded910c74b2190c368957c4ee mtd: nand: fsmc_nand: remove unnecessary platform_set_drvdata() 0c45084c9b2ab66af282193d43f736d02f5dcb1e mtd: nand: docg4: remove unnecessary platform_set_drvdata() 385f9c1ef89efaf4bd4d4f3236e81c755b8caddf mtd: nand: bf5xx_nand: remove unnecessary platform_set_drvdata() 65a561c4335f598a2e33239d25f4d1a1a4e0fcf1 mtd: nand: atmel_nand: remove unnecessary platform_set_drvdata() c27ed888870c52292fc322050ddf80e84aa0de4f mtd: nand: ams-delta: remove unnecessary platform_set_drvdata() 49649863a7dd1f3ee0c46320ff78856974e9772a mtd: nand: pxa3xx: Add support for Read parameter page command caa75d26a05fa5155855a86b58acb74e916c2328 mtd: nand: pxa3xx: Add address support for READID command a456431d85b37365bb324c48300781ec940fff99 mtd: nand: pxa3xx: Fix MODULE_DEVICE_TABLE declaration a6ab4f906eb96cfbaa8823e6668bb840020c3252 mtd: nand: pxa3xx: Use of_machine_is_compatible() c6bf90f74720c76ddededb035d335827b55e9c87 mtd: nand: pxa3xx: Set info->use_dma properly 98dde6f6ec74e855a206904c6e4f82baa041ca9a mtd: atmel_nand: add a new dt binding item for nand dma support 4df160fe6b080116a37ac90d4619983b71a3d21d mtd: atmel_nand: replace cpu_is_at32ap7000() with a nand platform data 40aeefd2d7b15037141a36bb99ee8ac0fc192d77 mtd: gpmi-nand: fix error return from gpmi_get_clks() 359a1df828b36e9a9994a23418544bc88c28074f mtd: nand: davinci: use devm_ioremap_resource() 6e0efb855af64ab8322a9eb523027fc8f6bc43f6 mtd: nand_base: Only use GET/SET FEATURES command on chips that support them. 9ab677c6bb897ef2108292996e66530cce66c2b9 mtd: nand: fsmc: update of OF support ff59928a191e881df9e267b93506ed016ac15a1a mtd: nand: pxa3xx: Move buffer release code to its own function 0c0412495b9b3481220ca2b550254749efcca2b9 mtd: nand: pxa3xx: Check for clk_prepare_enable() return value 9ecbf288af72b90c141dcfdd41a1159a41ca2992 mtd: nand: pxa3xx: Use clk_prepare_enable and clk_disable_unprepare 62f822b04664f2bb5259013dc033da773e6e47b8 mtd: nand: pxa3xx: Use devm_clk_get 9b948fb5b989ac8faf387968dd9e1de4b4fb2cb1 mtd: nand: pxa3xx: Use devm_ioremap_resource 7e4dd5c37fa010dd55c243e58e9c22a03d73687d mtd: nand: pxa3xx: Use devm_kzalloc 57646f659a8a9cdc52f1ad561efbe8df653ccba6 mtd: nand_base: Use io{read, write}*_rep functions for transfer b426958cc7b80a7bc82e2d93e2ad9324876fe982 mtd: nand-gpio: Add missing "owner" field in platform_driver struct 9822c3457e6664f6b7476fc0ccee242204b95272 mtd: nand-gpio: Rename internal variables to match functionality c9906128d056e743e0f207147e0f880b2242c047 mtd: nand-gpio: Unneeded dependency on ARM removed 38af907581d9397d41ee8237f3e67a7d1319a8ce mtd: nand-gpio: Use default nand_base {read/write}_buf functions dd6ca7acd8bebf280dbdb1d675732fa7f9cac8bd mtd: nand-gpio: Do not override GPIOs if driver uses platform_data but OF is enabled in 45078431a6ea64791ad8a72ac5860c0671ac53d4 mtd: nand-gpio: Use default dev_ready function if RDY is missing in configuration 055deba61df0a1e34d7682701babb62678f9ab9e mtd: nand-gpio: Convert driver to using resource-managed functions b6eec0dada833875d85a3c0917a394ad57dfb54b mtd: fsl_ifc_nand: set NAND_NO_SUBPAGE_WRITE 892bccd8efae6175dc9d8628627e347c526564d2 mtd: fsmc_nand: add CONFIG_PM_SLEEP to suspend/resume functions 18c40318889629ad2f767603b0f4b51ebb71e4de mtd: r852: add CONFIG_PM_SLEEP to suspend/resume functions 42def8ab25ecd8a81f1bd4b452445ed3636d159f mtd: fsl_ifc_nand: remove incorrect kfree() d855bd95ad35568b109f1b4587b68f0c950011f5 mtd: omap2: allow bulding as a module Best regards, -- Hector Palacios
On 09/19/2013 06:07 PM, Marek Vasut wrote: > Dear Huang Shijie, > > Sorry, I think I got lost in the discussion. I will pull out. > > btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm > trying to backport patches from -next and apply the GPMI NAND patchset, without > much luck yet. Oops, sorry, did you mean you were trying to backport them into U-Boot? Then please disregards my previous message. Best regards, -- Hector Palacios
Dear Hector Palacios, > On 09/19/2013 06:07 PM, Marek Vasut wrote: > > Dear Huang Shijie, > > > > Sorry, I think I got lost in the discussion. I will pull out. > > > > btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now > > I'm trying to backport patches from -next and apply the GPMI NAND > > patchset, without much luck yet. > > Oops, sorry, did you mean you were trying to backport them into U-Boot? > Then please disregards my previous message. You actually just saved me a lot of annoyance, thank you ;-) btw feel free to run into me on IRC (#u-boot on freenode) or jabber so we can work on the backporting-to-uboot part ;-) Best regards, Marek Vasut
Dear Hector Palacios, > On 09/19/2013 06:07 PM, Marek Vasut wrote: > > Dear Huang Shijie, > > > > Sorry, I think I got lost in the discussion. I will pull out. > > > > btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now > > I'm trying to backport patches from -next and apply the GPMI NAND > > patchset, without much luck yet. > > Oops, sorry, did you mean you were trying to backport them into U-Boot? > Then please disregards my previous message. After applying the batch of patches, this is what I get. Interestingly enough, this JFFS2 was written from FSL 2.6.35 kernel. [ 24.118091] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC error [ 24.164458] jffs2: mtd->read(0x1fa34 bytes from 0x5cc) returned ECC error [ 24.171377] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000005cc: 0x7953 i nstead [ 24.180969] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000005d0: 0xe837 i nstead [ 24.190675] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000005d8: 0x85ff i nstead [ 24.200274] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000005dc: 0xcde0 i nstead [ 24.209853] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000005e0: 0x7000 i nstead [ 24.219428] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000005e4: 0x020f i nstead [ 24.229000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000005e8: 0x0200 i nstead [ 24.238570] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000005ec: 0x2400 i nstead [ 24.248142] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000005f4: 0xa400 i nstead [ 24.257645] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000608: 0xacc8 i nstead [ 24.267191] jffs2: Further such events for this erase block will not be printed [ 24.275419] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000021c8: Read 0x00000000, cal culated 0xd5be0e0f [ 24.287221] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000049d4: Read 0xd1f00000, cal culated 0x34cb9a56 [ 24.300900] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0000b9c0: Read 0x7fd74190, cal culated 0xfdbc37a5 [ 24.312171] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0000d1f4: Read 0x16600000, cal culated 0x00cb3014 [ 24.326509] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000161d4: Read 0x9a500000, cal culated 0xcd68c7e3 [ 24.338761] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0001a1e4: Read 0x14500000, cal culated 0xa3e78a6c [ 24.352739] jffs2: mtd->read(0xc28 bytes from 0x1f3d8) returned ECC error [ 24.359661] jffs2: Empty flash at 0x0001f3d4 ends at 0x0001f400 [ 24.366953] jffs2: mtd->read(0xbec bytes from 0x1f414) returned ECC error [ 24.374053] jffs2: Empty flash at 0x0001f410 ends at 0x0001f604 [ 24.381408] jffs2: mtd->read(0x9e8 bytes from 0x1f618) returned ECC error [ 24.388450] jffs2: Empty flash at 0x0001f614 ends at 0x0001fa00 [ 24.395141] jffs2: mtd->read(0x5f4 bytes from 0x1fa0c) returned ECC error [ 24.402059] jffs2: Empty flash at 0x0001fa08 ends at 0x0001fc00 [ 24.408794] jffs2: mtd->read(0x3ec bytes from 0x1fc14) returned ECC error [ 24.415615] jffs2: Empty flash at 0x0001fc10 ends at 0x0001fca8 [ 24.422351] jffs2: mtd->read(0x350 bytes from 0x1fcb0) returned ECC error [ 24.429262] jffs2: Empty flash at 0x0001fcac ends at 0x0001fe04 [ 24.435930] jffs2: mtd->read(0x1e8 bytes from 0x1fe18) returned ECC error [ 24.443789] jffs2: mtd->read(0x100 bytes from 0x20000) returned ECC error [ 24.491452] jffs2: mtd->read(0x1f964 bytes from 0x2069c) returned ECC error Best regards, Marek Vasut
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c index cc0306b..5461189 100644 --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c @@ -217,6 +217,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data *this) if (geo->page_size < mtd->writesize + mtd->oobsize) { of->offset = geo->page_size - mtd->writesize; of->length = mtd->oobsize - of->offset; + printk("[ %s ] %d, %d\n", __func__, of->offset, of->length); } geo->payload_size = mtd->writesize;