Iqbal wrote: > Hi, > Looking deep into this lead me to an interesting point. > > Kevin's unlock flash device patch(commit: a34c2f3) switches the NOR flash into write or programming mode. Due to this, watchdog reset is causing the kernel to freeze. > Basically the u-boot sitting on the NOR flash is not read/executed because it is unlocked. The same issue is also relevant for OMAP2430 SDP board. There even warm reset button (S5) can't reset the board for the same reason. Due to the warm reset signal is not routed to NOR flash chips, the chips may stay in unpredictable (non-readable) state after the reset signal has been issued so CPU can not read its first instruction and all this looks like a hang. > > We can have a workaround by locking the device back on the completion of jffs2 booting or otherwise Kevin can suggest something else. As a workaround, we could unlock only needed partitions but leave the bootloader partition in locked state. There is actually a corresponding patch submitted to the MTD list some time ago -- http://lists.infradead.org/pipermail/linux-mtd/2007-November/019930.html. Using this approach its possible to unlock only root partition at boot time. But, users can do flash unlock whenever at run time so this approach does not save us from all related problems. It seems the only reliable solution is to route warm reset signal to NOR flash chips. Regards, Dmitry > > The actual patch is below. > > The bootloader may lock the flash device upon booting. This requires > the use of 'flash_unlock' on each partition before using them. > > However, when booting from flash the MTD driver is unable to "mark > space as dirty" since the device is locked. This results lots of boot > warnings from the MTD layer. > > The MTD driver for OMAP needs to unlock the device during init so > booting from flash can work without errors. > > Signed-off-by: Kevin Hilman <khilman@xxxxxxxxxx> > Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx> > > diff --git a/drivers/mtd/maps/omap_nor.c b/drivers/mtd/maps/omap_nor.c index a1342a2..d72cc11 100644 > --- a/drivers/mtd/maps/omap_nor.c > +++ b/drivers/mtd/maps/omap_nor.c > @@ -108,6 +108,10 @@ static int __devinit omapflash_probe(struct platform_device *pdev) > } > info->mtd->owner = THIS_MODULE; > > + /* Unlock the flash device. */ > + if (info->mtd->unlock) > + info->mtd->unlock(info->mtd, 0, info->mtd->size); > + > #ifdef CONFIG_MTD_PARTITIONS > err = parse_mtd_partitions(info->mtd, part_probes, &info->parts, 0); > if (err > 0) > > Regards > Iqbal > >> -----Original Message----- >> From: linux-omap-open-source-bounces@xxxxxxxxxxxxxx >> [mailto:linux-omap-open-source-bounces@xxxxxxxxxxxxxx] On >> Behalf Of Reddy, Teerth >> Sent: Monday, December 17, 2007 5:54 PM >> To: linux-omap@xxxxxxxxxxxxxxx >> Cc: linux-omap-open-source@xxxxxxxxxxxxxx >> Subject: Watchdog driver issue on OMAP3 >> >> >> >> Hi >> >> I am seeing this issue with the watchdog driver on >> OMAP3430,whenever the watchdog driver is closed the board >> should reboot but the board freezes after the watchdog >> timeout and I have to reboot the board manually to get the >> u-boot back. >> >> Is this an issue with the watchdog driver or is >> something else causing this? >> >> Best Regards, >> Teerth - 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
