Restart problems after writing to mtdblock?

Restart problems after writing to mtdblock?

[Paul Nash]

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

RE: Restart problems after writing to mtdblock?

[Paul Nash]

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@wildseed.com]
Sent: Wednesday, November 27, 2002 4:58 PM
To: 'linux-mtd@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/

Re: Restart problems after writing to mtdblock?

[Jörn Engel]

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.

Jörn

-- 
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

Re: Restart problems after writing to mtdblock?

[David Woodhouse]

paulnash@wildseed.com said:
>   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.

This kind of thing is usually caused by inappropriate use of drugs on the
part of the hardware designer, AFAICT.


paulnash@wildseed.com said:
> 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... 

It's been discussed before. IIRC the conclusion that it wouldn't be 100% 
reliable, and it was better to fix the hardware and confiscate the drugs.

--
dwmw2

RE: Restart problems after writing to mtdblock?

[Paul Nash]

Power fail is not a concern -- this only occurs in the case of a software
reboot of the chip without power loss.  An external reset is not an issue.
Flash chips don't store state as to their last read mode across power
failure anyway.

-----Original Message-----
From: Jörn Engel [mailto:joern@wohnheim.fh-wedel.de] 
Sent: Wednesday, November 27, 2002 11:39 PM
To: Paul Nash
Cc: linux-mtd@lists.infradead.org
Subject: Re: Restart problems after writing to mtdblock?


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.
> 

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.

Jörn

Re: Restart problems after writing to mtdblock?

[David Woodhouse]

paulnash@wildseed.com said:
>  Power fail is not a concern -- this only occurs in the case of a
> software reboot of the chip without power loss.  An external reset is
> not an issue. Flash chips don't store state as to their last read mode
> across power failure anyway. 

I wouldn't swear to that. You could feasibly have a power outage long 
enough to reset most of the board, but the flash chips don't draw much 
power and could perhaps retain their state.

Unlikely perhaps, but I wouldn't declare it impossible.


--
dwmw2

RE: Restart problems after writing to mtdblock?

[Paul Nash]

A very good point, well taken.  In the particular case of our board, a power
supply drop out supervisor will cause a hold-off period and the entire reset
system will likely chain off that, but that's pretty specific to our design.

Anyway, we're pursuing the obvious "right solution" and looking at other
mechanisms for interim fixes.  Thanks all...

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org] 
Sent: Saturday, November 30, 2002 8:23 AM
To: Paul Nash
Cc: 'Jörn Engel'; linux-mtd@lists.infradead.org
Subject: Re: Restart problems after writing to mtdblock? 



paulnash@wildseed.com said:
>  Power fail is not a concern -- this only occurs in the case of a 
> software reboot of the chip without power loss.  An external reset is 
> not an issue. Flash chips don't store state as to their last read mode 
> across power failure anyway.

I wouldn't swear to that. You could feasibly have a power outage long 
enough to reset most of the board, but the flash chips don't draw much 
power and could perhaps retain their state.

Unlikely perhaps, but I wouldn't declare it impossible.


--
dwmw2