Iqbal,
On 1/7/08, Iqbal <iqbal@xxxxxx> wrote:
> > reset exactly when jffs2 is in the middle of a write.. but I
> > guess u'd have already looked at it.
> I agree, but I am doing watchdog reset just after a clean NFS boot, note it is not JFFS2 boot.
> The unlock is done with in the probe and nobody is accessing NOR.
> I don't suspect any write between my kernel NFS boot and wdt reset.
I checked this issue on a 2420, looks like for some reason, the
explicit call to unlock seems to put the device in some status state,
the following patch seems to work.. but the real "fix" could be in cfi
driver."drivers/mtd/chips/cfi_cmdset_0001.c" cfi_intelext_unlock I
think.. maybe you need to ask the mtd list.
---
MTD:ARM: Work around for a possible unlock issue in cfi_cmdset unlock func
On calling unlock, the driver should ideally put the device back in
readable state, instead it might be in status mode
workaround this by forcing a dummy read op after a unlock
---
drivers/mtd/maps/omap_nor.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/maps/omap_nor.c b/drivers/mtd/maps/omap_nor.c
index d72cc11..9f58dd1 100644
--- a/drivers/mtd/maps/omap_nor.c
+++ b/drivers/mtd/maps/omap_nor.c
@@ -111,6 +111,14 @@ static int __devinit omapflash_probe(struct
platform_device *pdev)
/* Unlock the flash device. */
if (info->mtd->unlock)
info->mtd->unlock(info->mtd, 0, info->mtd->size);
+ /* HACK by a forcing a dummy read To reset the partition to readable
+ * TODO: a real fix is by fixing unlock function
+ */
+ if (info->mtd->read) {
+ u_char val;
+ size_t len = sizeof(val);
+ info->mtd->read(info->mtd, 0,len,&len, &val);
+ }
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info->mtd, part_probes, &info->parts, 0);
-
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
