RE: Power blackouts and brownouts

RE: Power blackouts and brownouts

[Vipin Malik]

Well, I haven't seen any flash chips without a reset line, not to say that
they aren't out there.

With a flash chip *with* a reset line, and one which is connected to the
system reset, and assuming that the reset gets asserted in a power down, up,
and brown condition, then everything is ok.

JFFS(2) are designed for this situation and will (are supposed to)
successfully recover on the next power up and all your writes that got
written with CRC will be there. Any write that did not get completed will
not be there at all. If you were overwriting a portion of an existing file,
then the original portion will (should) be still there.

The case of the *no flash chip reset* line is more complicated and you can
have the following situations, particularly in brownouts:

1. Flash chip gets reset as internal VCC monitoring threshold is
(numerically) greater than the system (CPU) reset threshold. In this case,
your flash chip state machine will get reset. In this case there are 2
conditions:
  a. If the flash chip was not being written to or read from, there is no
effect
  b. If the flash chip was being written to, it's state m/c will get reset
and most likely it's generate a fatal error in the JFFS or MTD write code.
You are unlikely to recover from this as the code is not written to retry
"fatal" errors like the state m/c getting reset in the middle of an
operation (AFAIK).

2. The processor gets reset in a brown out, but not the flash chip. Again
you have 2 conditions:
  a. If the flash chip was in the "default" read state, no problem as the
processor will expect and find it readable. Life is good.
  b. If the flash was in some other state (erasing or write), depending on
how fast the processor comes back up and tries to access the flash, the
flash may or may not respond to a read request. You are then hosed.

In summary, if your hardware is designed "right" you do not (read: should
not) have to worry about file system inconsistency problems as any data
corruption issues are taken care of by JFFS(2) design.

What type of flash chips do not have a hardware reset line? Any examples?

Vipin
P.S. All this is IMHO (In my humble opinion) of course. And that opinion has
been known to be fallable and wrong in more than one occasion in the past!
 

-----Original Message-----
From: Chris Read
To: 'mtd@infradead.org'
Sent: 4/26/01 8:06 AM
Subject: Power blackouts and brownouts

Does anyone know what actually happens to a flash chip when the power 
starts to fail during an erase or a write cycle? We are all trying to
write 
code which can recover when abruptly halted at any point, but can all
the 
devices which we are using claim the same?

I have noticed that several flash devices have a power on reset line;
most 
however do not. Whilst I appreciate that flash devices are not fully
static 
like SRAM or EPROM, and therefore must have some way of initialising in
a 
known state at power up; most devices appear to not need this external 
signal. My hypothesis is therefore that this line may be more for
abruptly 
stopping any internal state machine during the first stages of a
brown-out 
whilst there is still sufficient power available to do so.

Any thoughts?

Chris Read




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: Power blackouts and brownouts

[Joakim Tjernlund]

-----Original Message-----
From: owner-mtd@infradead.org [mailto:owner-mtd@infradead.org]On Behalf

Well, I haven't seen any flash chips without a reset line, not to say that
they aren't out there.

With a flash chip *with* a reset line, and one which is connected to the
system reset, and assuming that the reset gets asserted in a power down, up,
and brown condition, then everything is ok.

<snip>

hmm, do you mean that reset has to asserted at power DOWN as well in order
for JFFS2 FS to manage its FS? How do you manage that when someone pulls
the power cable?

         Jocke



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Power blackouts and brownouts

[Vipin Malik]

Joakim Tjernlund wrote:

> -----Original Message-----
> From: owner-mtd@infradead.org [mailto:owner-mtd@infradead.org]On Behalf
>
> Well, I haven't seen any flash chips without a reset line, not to say that
> they aren't out there.
>
> With a flash chip *with* a reset line, and one which is connected to the
> system reset, and assuming that the reset gets asserted in a power down, up,
> and brown condition, then everything is ok.
>
> <snip>
>
> hmm, do you mean that reset has to asserted at power DOWN as well in order
> for JFFS2 FS to manage its FS? How do you manage that when someone pulls
> the power cable?
>
>          Jocke

No, but most well designed embedded systems will assert the reset line both on
power
up AND down. Actually, direction does not really matter. Reset is asserted when
the
power rail is out of spec, which will happen (due to the laws of physics), both
on up and down.

You wan't the reset line asserted on power down also, else the processor may
"wander off"
into the weeds and overwrite battery backed RAM or other such stuff if present.

I don't think that JFFS(2) *require* you to assert the reset line (processor or
flash) on power down.

Vipin




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Power blackouts and brownouts

[David Woodhouse]

vipin.malik@daniel.com said:
>  No, but most well designed embedded systems will assert the reset
> line both on power up AND down. Actually, direction does not really
> matter. Reset is asserted when the power rail is out of spec, which
> will happen (due to the laws of physics), both on up and down.

> You wan't the reset line asserted on power down also, else the
> processor may "wander off" into the weeds and overwrite battery backed
> RAM or other such stuff if present.

Note that 'well designed embedded systems' does _not_ include the Intel
Assabet platform. I believe nothing ever asserts the flash reset line, so if
you reset while the flash is in a mode other than read mode, the CPU's reset
vector is pointing at status words :)

The only way to fix it when you've done this is to remove power, remove the 
battery, and wait for the on-board cap to run out of charge.

Fun. :)

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Power blackouts and brownouts

[Vipin Malik]

Well, with a name like "ass-a-bet" what can you expect ;)

What is this platform anyway?

Vipin

David Woodhouse wrote:

> vipin.malik@daniel.com said:
> >  No, but most well designed embedded systems will assert the reset
> > line both on power up AND down. Actually, direction does not really
> > matter. Reset is asserted when the power rail is out of spec, which
> > will happen (due to the laws of physics), both on up and down.
>
> > You wan't the reset line asserted on power down also, else the
> > processor may "wander off" into the weeds and overwrite battery backed
> > RAM or other such stuff if present.
>
> Note that 'well designed embedded systems' does _not_ include the Intel
> Assabet platform. I believe nothing ever asserts the flash reset line, so if
> you reset while the flash is in a mode other than read mode, the CPU's reset
> vector is pointing at status words :)
>
> The only way to fix it when you've done this is to remove power, remove the
> battery, and wait for the on-board cap to run out of charge.
>
> Fun. :)
>
> --
> dwmw2



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Power blackouts and brownouts

[David Schleef]

On Fri, Apr 27, 2001 at 03:34:32PM +0100, David Woodhouse wrote:
> 
> Note that 'well designed embedded systems' does _not_ include the Intel
> Assabet platform. I believe nothing ever asserts the flash reset line, so if
> you reset while the flash is in a mode other than read mode, the CPU's reset
> vector is pointing at status words :)

This is also a problem for soft-reset.  (Been there, dont that.)
That's why the Sharp chip driver always puts the chips into read
mode after checking the status.  I believe at least one of the
other chip drivers don't do this.



dave...



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Power blackouts and brownouts

[David Woodhouse]

ds@schleef.org said:
>  This is also a problem for soft-reset.  (Been there, dont that.)
> That's why the Sharp chip driver always puts the chips into read mode
> after checking the status.  I believe at least one of the other chip
> drivers don't do this. 

This bit me too, on suspend/resume. We now have MTD suspend/resume 
functions which deal with that case.

Incidentally, is there any particular reason why the functionality of the 
sharp driver shouldn't be provided by a more generic version of the Intel/
Sharp CFI commandset driver? Once we fix up the probe, of course.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: sharp driver dissimilarities

[David Schleef]

On Sat, Apr 28, 2001 at 11:34:45AM +0100, David Woodhouse wrote:
> 
> Incidentally, is there any particular reason why the functionality of the 
> sharp driver shouldn't be provided by a more generic version of the Intel/
> Sharp CFI commandset driver? Once we fix up the probe, of course.

I tried and failed, but that may be just my lack of understanding
of the CFI driver.  The commands, command write locations, and
status bits have no similarity to other chip drivers.




dave...



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: sharp driver dissimilarities

[David Woodhouse]

ds@schleef.org said:
>  I tried and failed, but that may be just my lack of understanding of
> the CFI driver.  The commands, command write locations, and status
> bits have no similarity to other chip drivers.

The commands certainly have some similarity with the cfi_cmdset_0001 code, 
which isn't particularly surprising as command set 0001 is 'Intel/Sharp'.

However, at the time you did sharp.c, I believe that CFI code wasn't 
sufficiently generic to deal with 4x8-bit chips. It ought to manage that 
now, though.

        /* Clear the status register first */
        cfi_write(map, CMD(0x50), adr);

        /* Now erase */
        cfi_write(map, CMD(0x20), adr);
        cfi_write(map, CMD(0xD0), adr);

We really ought to separate the backends which actually drive the chips from 
the probe code.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: sharp driver dissimilarities

[David Schleef]

On Sat, Apr 28, 2001 at 05:11:57PM +0100, David Woodhouse wrote:
> 
> ds@schleef.org said:
> >  I tried and failed, but that may be just my lack of understanding of
> > the CFI driver.  The commands, command write locations, and status
> > bits have no similarity to other chip drivers.
> 
> The commands certainly have some similarity with the cfi_cmdset_0001 code, 
> which isn't particularly surprising as command set 0001 is 'Intel/Sharp'.

Heh...

> However, at the time you did sharp.c, I believe that CFI code wasn't 
> sufficiently generic to deal with 4x8-bit chips. It ought to manage that 
> now, though.

I'm not sure that was the case.  I'd chalk it up to be not being
very observant.

I actually started from the cfi_cmdset_0001.c driver.  In the
process, I noticed a few things that I don't like about it.

The write process uses word_write_time and adjusts it so that it
settles at the average write time.  The problem with that
method is that half the time, you will be sleeping for 10 ms
on something that may finish in 1 more usec of waiting.  Not
pretty.  The sharp driver write speed went up by a factor of
about 10 when I fixed that.  It just uses the braindead "spin
on the status register" for ~100 us.  Perhaps some kind of
hybrid is better, but schedule_timeout is a significant
performance hit.

A similar thing is true about block erase -- the schedule_timeout(HZ)
means that the earliest time the driver will notice that the
chip is done erasing is 1 s.

I also didn't understand how the locking was supposed to work,
so I rewrote it in the sharp driver.  I like it better.

On the other hand, of course, the sharp driver only handles
one interleve.





dave...



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: sharp driver dissimilarities

[David Woodhouse]

ds@schleef.org said:
>  The write process uses word_write_time and adjusts it so that it
> settles at the average write time.  The problem with that method is
> that half the time, you will be sleeping for 10 ms on something that
> may finish in 1 more usec of waiting.

We only sleep for that long if current->need_resched.

But you're right that udelay() is fairly pointless - we should just spin 
polling the flash. Assuming there aren't power consumption issues - but as 
udelay is always a CPU spin anyway, I think that's OK.


ds@schleef.org said:
>  A similar thing is true about block erase -- the schedule_timeout(HZ)
> means that the earliest time the driver will notice that the chip is
> done erasing is 1 s. 

There's a tradeoff here between performance of the flash driver and 
performance of the rest of the system. We should probably sleep only if 
current->need_resched, I suppose.


ds@schleef.org said:
>  I also didn't understand how the locking was supposed to work, so I
> rewrote it in the sharp driver.  I like it better. 

The problem with having a single generic _wait function is that they're not 
actually the same. When you want to read, you can interrupt erases or 
writes. When you want to write, you can interrupt erases.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: Power blackouts and brownouts

[Hicks, Jamey]

On the Intel chips, the reset line seems to be most useful to force the
chip into a very low power standby mode.

The specs for recent Intel and AMD flash chips that I have read claim to
halt programming or erasing when the supply voltage drops below
acceptable levels.

So now you just need to worry about which part of the system browns out
first, whether there are voltage monitors on all the supplies, etc.

Jamey Hicks



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Power blackouts and brownouts

[Chris Read]

Does anyone know what actually happens to a flash chip when the power 
starts to fail during an erase or a write cycle? We are all trying to write 
code which can recover when abruptly halted at any point, but can all the 
devices which we are using claim the same?

I have noticed that several flash devices have a power on reset line; most 
however do not. Whilst I appreciate that flash devices are not fully static 
like SRAM or EPROM, and therefore must have some way of initialising in a 
known state at power up; most devices appear to not need this external 
signal. My hypothesis is therefore that this line may be more for abruptly 
stopping any internal state machine during the first stages of a brown-out 
whilst there is still sufficient power available to do so.

Any thoughts?

Chris Read




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Power blackouts and brownouts

[Bari Ari]

Chris Read wrote:

> Does anyone know what actually happens to a flash chip when the power 
> starts to fail during an erase or a write cycle? We are all trying to write 
> code which can recover when abruptly halted at any point, but can all the 
> devices which we are using claim the same?
> 
> I have noticed that several flash devices have a power on reset line; most 
> however do not. Whilst I appreciate that flash devices are not fully static 
> like SRAM or EPROM, and therefore must have some way of initialising in a 
> known state at power up; most devices appear to not need this external 
> signal. My hypothesis is therefore that this line may be more for abruptly 
> stopping any internal state machine during the first stages of a brown-out 
> whilst there is still sufficient power available to do so.
> 
> Any thoughts?
> 
> Chris Read

The answer depends on how the circuit designer engineered the power 
supplies and reset circuitry. How well was the circuit engineered to 
account for power failure and to minimize data corruption? The flash 
device characteristics are only part of the puzzle.

In one scenario the power supply for the flash device may hold within 
spec longer than the driver writing the data to it, in this scenario the 
flash device operates correctly and latches the data to its input 
register but the data latched may already be garbage based on the output 
driver from the device writing data to the data inputs on the flash 
since the drivers supply voltage is below spec at that clock edge when 
the data is latched.

Bari Ari                         email: bari@onelabs.com 
<mailto:bari@onelabs.com> <mailto:bari@onelabs.com>
O.N.E. Technologies
1505 Old Deerfield Road        tel: 773-252-9607
Highland Park, IL 60035        fax: 773-252-9604

http://www.onelabs.com




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org