On Mon, Oct 4, 2010 at 12:59 PM, Ghorai, Sukumar <s-ghorai@xxxxxx> wrote: > > >> -----Original Message----- >> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Ghorai, Sukumar >> Sent: Tuesday, September 28, 2010 6:17 PM >> To: linux-mtd@xxxxxxxxxxxxxxxxxxx >> Cc: linux-omap@xxxxxxxxxxxxxxx >> Subject: Issue : jffs2 and ecc layout >> >> Hi, >> I was using the following ecc layout which is not working to mount the >> jffs2 File-system. I was in 2.6.32 kernel and working; but same layout is >> not working with latest 2.6 kernel. >> >> Observation is that - no read request issued to the driver (say omap2.c). >> >> # mount -t jffs2 /dev/mtdblock4 /mnt/nand >> [ 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes, read >> 0 bytes, error -22 >> mount: Mounting /dev/mtdblock4 on /mnt/nand failed: Input/output error >> >> # dmesg >> <3>[ 32.505218] cannot read OOB for EB at 00000000, requested 8 bytes, >> read 0 bytes, error -22 >> I do not think above issue has anything to do with the ECC layout. But as I earlier pointed (in [1]), this change [2] has messed up function 'omap_hwcontrol'. All read/write functions read/write data from/to address info->nand.IO_ADDR_(R/W), which is not set by new function 'gpmc_nand_write' (which still take care of writing address/cmd to write registers). But since above pointer is not set (hence points to address '0'), driver tries to read data from wrong location. In fact, I would even suggest to try dumping nand command registers(or use T32) and verify if commands issued were written correctly to appropriate registers. [1]: http://marc.info/?l=linux-omap&m=128302624528822&w=2 [2] commit: http://git.infradead.org/mtd-2.6.git/commitdiff/2c01946c6b9ebaa5a89710bc42ca224a7f52f227 -- Regards, Vimal Singh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
