This patch should fix the following problem:
1. the jffs2-image update in the u-boot was ok
2. first restart and first mount of the NAND-flash-partition was also ok
3. before the restart of controller there are no any activity on NAND-flash
except of the jffs2_gcd_mtdX-process ...
4. BUT after the second restart the NAND-flash-partition could not be really
used after the second mount,
dmesg filled with messages:
...
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03ce0000: 0xc0ff
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03d00000: 0xc0ff
instead
....
Just for for info:
the behaviour observed on mpc8313-based board with the large-page NAND.
The only activity on NAND-flash was the garbage collector process, that looks
for CLEANMARKER-nodes
As Scott said it was broken by commit 3ab8f2a2e7011c5e83363b42950757e46ef06824
Signed-off-by: Sergej Stepanov <sergej.stepa...@ids.de>
Cc: Rolf Riehle <rolf.rie...@ids.de>
Cc: Scott Wood <scottw...@freescale.com>
Cc: David Woodhouse <dw...@infradead.org>
--
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index c141b07..7a13d42 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -388,6 +388,8 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned
int command,
"page_addr: 0x%x, column: 0x%x.\n",
page_addr, column);
+ elbc_fcm_ctrl->column = column;
+ elbc_fcm_ctrl->oob = 0;
elbc_fcm_ctrl->use_mdr = 1;
fcr = (NAND_CMD_STATUS << FCR_CMD1_SHIFT) |
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
