Restart problems after writing to mtdblock?

Paul Nash paulnash at wildseed.com
Wed Nov 27 21:33:31 EST 2002


Partially answering my question, it looks like I was partly correct.  It
appears that MTD is setup to lazily delay a reset to read array mode until
an actual read request comes along.  In my case, this is fatal.

I'm wondering if a reasonable solution is to do something like install a
reboot_notifier so I can guarantee the chip is back in Read Array mode.
Where would be a good place to do such a thing, or if this is a bad idea,
what is a better one?  Thanks...

-Paul


-----Original Message-----
From: Paul Nash [mailto:paulnash at wildseed.com]
Sent: Wednesday, November 27, 2002 4:58 PM
To: 'linux-mtd at lists.infradead.org'
Subject: Restart problems after writing to mtdblock?


On 2.4.18, we're experiencing a problem where if we write some partition
through /dev/mtdblock (by opening, writing and closing in code, not from the
shell) when we close the device (and it's corresponding mtdchar device) and
then call reboot() with the restart option, the syste fails to successfully
restart.

I'm quite certain that what's happening is the flash chip (intel 640J part,
1x16 arrangement) is not being taken out of Read Array mode, so the
bootloader can't fetch instructions.  On our StrongARM board at the moment,
we don't have nRESET_OUT fed into the flash chip.  We're investingating
that, but I would like to knoew the root cause.

What's really weird is that if I go to the shell and cat file >
/dev/mtdblock/<id> and then reboot via the same system call, everything
works fine.  On the one hand, a bunch of syncs happen when busybox does the
reboot, but on the other hand, this particular partition is not a mounted
filesystem, and we tried inserting some sync() calls as well.

I notice that cfi_cmdset_0001.c, for instance, doesn't explicitly put the
chip into Read Array mode after completeing a buffer write or erase block
operation.  The intel datasheet generally recommends this.  Is there any
harm in it?  It looks like maybe the driver waits until a read operation is
requested before doing this?

Help greatly appreciated...


-Paul


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/




More information about the linux-mtd mailing list