Restart problems after writing to mtdblock?

Jörn Engel joern at
Thu Nov 28 02:39:27 EST 2002

On Wed, 27 November 2002 18:33:31 -0800, Paul Nash wrote:
> 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...
>> 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.

Frankly, if the hardware doesn't reset the flash chips on reboot, you
have broken hardware and have to deal with it.
A reboot_notifier would work, unless you have a power fail. Not good.

Hacking cfi_cmdset_0001.c to bring the chips back into read mode
whenever possible would work better, breaking only on power fail
during a write or erase operation. Still not good.

So, unless you want to live with the problem, there is no alternative
to fixing the hardware.


You can't tell where a program is going to spend its time. Bottlenecks
occur in surprising places, so don't try to second guess and put in a
speed hack until you've proven that's where the bottleneck is.
-- Rob Pike

More information about the linux-mtd mailing list