[Fwd: power down]
Quoted 5 lines · Bob Canup
The reason that I said that expecting anything to work during power down is wishful thinking is this: once the voltage to a digital chip goes below the minimum specification of the chip, the behavior of the chip becomes indeterminate.
That's why the stuff you need to protect during a power down (SRAM say), has
its own backup battery and writes to the SRAM are shut off as soon as the system voltage falls below the operational threshold.
Quoted 5 lines
For example: the old Western Digital 1791 double density disk controller chip would sometimes glitch in such a way during power down that it would write to the floppy - you could see the floppy light blink when this happened.
Someone's buggy design does not mean that a better way does not exist. Obviously the chip was buggy if it exhibited this behavior.
Quoted 4 lines
Unless chips are specifically designed to handle power down conditions this sort of thing happens. For example - any competently designed Flash memory has to refuse to write if the voltage is below spec.
This is true. Flash chips will not initiate a write if power is not within specs. So this helps design a system that CAN survive random power downs.
Quoted 6 lines
As to flushing the buffers and doing a shutdown when a power fail condition occurs - I believe that Linux already has code to handle a power down such as I described. What I have described is very similar to a UPS signaling the kernel that power is going down. Linux can do an ordered shutdown when it receives the signal.
Unfortunately the times involved are an order of magnitude different. An embedded system may not have more than a few hundred milliseconds at best. a UPS will provide a few minutes of power at worst. If the lowest layers (in this case MTD) cannot guarantee handling of power downs, how will the upper layer help?
Quoted 5 lines
Qualifying digital circuitry with a POWER GOOD signal is very similar to protecting the circuitry with a typical 'SCR over voltage crowbar circuit': it makes the engineer feel good - but it doesn't actually do much of anything.
I'm sorry. I do not agree with this one bit. A low voltage detect generated reset signal can gate (stop) writes to SRAM within sub 1 nano seconds intervals. Don't see how the SCR analogy is relevant here.
Quoted 9 lines
Why doesn't the crowbar work? After all, it is a text book circuit. The answer is that the SCR is a power device which takes on the order of 10 microseconds to turn on while the delicate chips are destroyed by a few nanoseconds of over voltage. The result is that the SCR never turns on - the fuse blows because the weakest digital chip shorts the power supply to ground. One could "protect" SCR's with digital chips, but not the other way around.
Quoted 6 lines
Another example of "feel good engineering" is the power on self test which most computers have. One can only test non critical sections of the machine: if anything critical is broken the POST won't run - and a tech will have to figure out what is wrong. It's a bit like asking yourself "Am I alive?" If you can ask the question the answer is always "Yes".
Actually this can be a very good answer to why we are on this planet! If we weren't we would not be asking the question!! Anyway not relevant here :)
<desperate plea>
Come on guys (and gals). Am I championing a lost cause here? Have we given up on power down reliability of nonvolatile data in embedded systems under Linux?
Is anyone interested in this!? Lurkers please respond. How many people read this list anyway?
</desperate plea>
Quoted 2 lines
To unsubscribe, send "unsubscribe mtd" to [email protected]
Vipin Malik
Daniel Industries
[email protected]
All content my views and not my employers etc. etc.
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 2 lines · Vipin Malik
Quoted 1 line · Bob Canup
I don't think that you understand what we're trying to tell you. There is a difference in philosophy.
If you are running a flash as a normal read - write imitation of a disk there are severe time limitations as to how long the flash is going to work because of the limit on write cycles which flash technology has. As has been pointed out in an earlier post - one write a second will ruin a flash chip in a few weeks - which is not a very long for an embedded system to work.
Because of this limitation most of the people in this group who do design with flash use it in a Write Rarely Read Mostly manner. The only time the flash is written to is when there is a firmware upgrade. This is also the manner in which flash chips are used on conventional PC motherboards - if you lose power during a firmware upgrade - you are in trouble - nor do I see any practical method of handling that problem.
If you are trying to use the flash in a data - logging application where the file system has to be read - write to store data you are very quickly going to run into the write cycle limitations of the technology. I don't think that flash is the correct technology to use in such an application.
We use our DOC2000 in read only mode - with things like /var in volatile ram disk - we have found this to be a satisfactory way of doing things.
Now - as to the issue of a POWER GOOD signal. The inverse of a POWER GOOD signal is *POWER BAD. The reason for sending this signal to a chip is to tell it that it won't function properly if it attempts to perform its operation. But if the power is bad the chip is not working properly so it can't respond properly to the *POWER BAD signal. This is the equivalent of saying to a dead man "You're dead". That is true - but it does little good to tell him that.
That is the reason that there are no POWER GOOD input pins on anybody's chips. In addition the analog detectors which generate the *POWER BAD signal do not respond in nanoseconds - that is the reason for my analogy to the SCR crowbar. By the time that the analog detectors respond you have been operating the chips out of spec for a long time by digital standards.
Now because of the Yin and Yang nature of reality there can be some use to a properly designed power fail detection circuit - but the way they are mostly used is as a placebo.
To unsubscribe, send "unsubscribe mtd" to [email protected]
I am actually extremely interested in this issue, although I am not very qualified to present possible solutions. I am primarily a systems and software guy and have been constructing an embedded linux system which boots off an M-Systems DOC2000 and runs mostly out of ram disk. The board I am using has a watchdog timer which could spuriously reset the board (just like hitting the reset button on your PC). Power failures are also a reality I must deal with. I must at least make an attempt to guarantee that the system will always come back up (the damaged DOC2000 filesystem will be repaired by e2fsck upon subsequent boot up). To give you an idea of what/when I am doing flash writes, I am running postgres whose db files are in flash and am doing about a 20-100 byte record insert per minute (on average). The log files in /var/log/* are also in flash. There are no custom apps which write often to syslog and I am not running mail (although I am running apache which I could, but haven't yet turned off logging for). I mount the DOC2000 on /usr, but write only to the logs and db files (I have 'chattr i' on all other files in /usr). What I would like to get an opinion on is:
1) What is the probability that e2fsck will not be able to reapair the filesystem?
2) What is the probability that I will damage the boot sector and lilo will not be able to being to boot at all?
3) Since I use a pretty standard 5/12 V switching power supply and embedded PC board (a 40W compact version of a standard PC power supply w/o fan), do I have any hope in making HW or SW changes to possibly reduce or fix this problem?
Any suggestions or insight much appreciated.
Regards,
Jon
----- Original Message -----
From: Vipin Malik <[email protected]>
To: MTD <[email protected]>
Sent: Monday, December 06, 1999 3:41 PM
Subject: [Fwd: power down]
Quoted 89 lines
Quoted 5 lines · Bob Canup
The reason that I said that expecting anything to work during power down is wishful thinking is this: once the voltage to a digital chip goes below the minimum specification of the chip, the behavior of the chip becomes indeterminate.
That's why the stuff you need to protect during a power down (SRAM say), has
its own backup battery and writes to the SRAM are shut off as soon as the system voltage falls below the operational threshold.Quoted 5 lines
For example: the old Western Digital 1791 double density disk controller chip would sometimes glitch in such a way during power down that it would write to the floppy - you could see the floppy light blink when this happened.
Someone's buggy design does not mean that a better way does not exist. Obviously the chip was buggy if it exhibited this behavior.
Quoted 4 lines
Unless chips are specifically designed to handle power down conditions this sort of thing happens. For example - any competently designed Flash memory has to refuse to write if the voltage is below spec.
This is true. Flash chips will not initiate a write if power is not within specs. So this helps design a system that CAN survive random power downs.
Quoted 6 lines
As to flushing the buffers and doing a shutdown when a power fail condition occurs - I believe that Linux already has code to handle a power down such as I described. What I have described is very similar to a UPS signaling the kernel that power is going down. Linux can do an ordered shutdown when it receives the signal.
Unfortunately the times involved are an order of magnitude different. An embedded system may not have more than a few hundred milliseconds at best. a UPS will provide a few minutes of power at worst. If the lowest layers (in this case MTD) cannot guarantee handling of power downs, how will the upper layer help?
Quoted 5 lines
Qualifying digital circuitry with a POWER GOOD signal is very similar to protecting the circuitry with a typical 'SCR over voltage crowbar circuit': it makes the engineer feel good - but it doesn't actually do much of anything.
I'm sorry. I do not agree with this one bit. A low voltage detect generated reset signal can gate (stop) writes to SRAM within sub 1 nano seconds intervals. Don't see how the SCR analogy is relevant here.
Quoted 9 lines
Why doesn't the crowbar work? After all, it is a text book circuit. The answer is that the SCR is a power device which takes on the order of 10 microseconds to turn on while the delicate chips are destroyed by a few nanoseconds of over voltage. The result is that the SCR never turns on - the fuse blows because the weakest digital chip shorts the power supply to ground. One could "protect" SCR's with digital chips, but not the other way around.
Quoted 6 lines
Another example of "feel good engineering" is the power on self test which most computers have. One can only test non critical sections of the machine: if anything critical is broken the POST won't run - and a tech will have to figure out what is wrong. It's a bit like asking yourself "Am I alive?" If you can ask the question the answer is always "Yes".
Actually this can be a very good answer to why we are on this planet! If we weren't we would not be asking the question!! Anyway not relevant here :)
<desperate plea>
Come on guys (and gals). Am I championing a lost cause here? Have we given up on power down reliability of nonvolatile data in embedded systems under Linux?Is anyone interested in this!? Lurkers please respond. How many people read this list anyway?
</desperate plea>Quoted 2 lines
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 7 lines
Vipin Malik
Daniel Industries
[email protected]
All content my views and not my employers etc. etc.To unsubscribe, send "unsubscribe mtd" to [email protected]
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 3 lines · [email protected] said:
<desperate plea> Come on guys (and gals). Am I championing a lost
cause here? Have we given up on power down reliability of nonvolatile data in embedded systems under Linux?
Power down reliability of such data is an absolute must. I expect embedded systems using NFTL and ext3 to be absolutely reliable even if the plug is pulled half-way through a write.
This means we end up with two separate journalling / logging mechanisms - one at the block device level (ext3) and one at the flash media level (NFTL). As I said - ideally, we ditch that in the end and have a journalling/log-structured filesystem directly on the flash media.
Quoted 2 lines
Is anyone interested in this!? Lurkers please respond. How many people read this list anyway? </desperate plea>
infradead /var/lib/majordomo/lists $ wc -l mtd
64 mtd
--
dwmw2
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 4 lines
I mount the DOC2000 on /usr, but write only to the logs and db files (I have 'chattr i' on all other files in /usr). What I would like to get an opinion on is:
If you mount the doc2000 on /usr and have evrything else in ramdisk, perhaps mount /usr read-only. It won't corrupt that way.
TTYL,
Adi
To unsubscribe, send "unsubscribe mtd" to [email protected]
I would have NEVER thought of that! Too bad I need to write to this partition (as detailed in the rest of my message that you did not include here). I have a database on board which needs persistent storage. And yes, I have thought of the previously mentioned options of running everything in ramdisk and periodically moving files to the flash. Of course, odds say this is less susceptible to corruption, but I don't have enough ram (I am using the biggest SIMM my board will take already) for this.
-Jon
----- Original Message -----
From: Adi Linden <[email protected]>
To: Jon Burford <[email protected]>
Cc: Vipin Malik <[email protected]>; MTD <[email protected]>
Sent: Monday, December 13, 1999 6:49 AM
Subject: Re: [Fwd: power down]
Quoted 2 lines
Quoted 2 lines
I mount the DOC2000 on /usr, but write only to the logs and db files (I
have
Quoted 1 line
Quoted 1 line
'chattr i' on all other files in /usr). What I would like to get an
opinion
Quoted 11 lines
Quoted 1 line
on is:
If you mount the doc2000 on /usr and have evrything else in ramdisk, perhaps mount /usr read-only. It won't corrupt that way.
TTYL,
AdiTo unsubscribe, send "unsubscribe mtd" to [email protected]
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 5 lines · Bob Canup
Quoted 2 lines · Vipin Malik
Quoted 1 line · Bob Canup
Quoted 8 lines
I don't think that you understand what we're trying to tell you. There is a difference in philosophy.
If you are running a flash as a normal read - write imitation of a disk there are severe time limitations as to how long the flash is going to work because of the limit on write cycles which flash technology has. As has been pointed out in an earlier post - one write a second will ruin a flash chip in a few weeks - which is not a very long for an embedded system to work.
Assuming load levelling across a 4mb flash drive, if you average 4kb per write and write once per second continously you will write each sector a about 40 times per day.
AMD specs a minimum program/erase cycles of 100,000 per sector (flash sector) and 1,000,000 per device. To reach 100,000 writes at 50 per day would take over 5 years.
Quoted 6 lines
Because of this limitation most of the people in this group who do design with flash use it in a Write Rarely Read Mostly manner. The only time the flash is written to is when there is a firmware upgrade. This is also the manner in which flash chips are used on conventional PC motherboards - if you lose power during a firmware upgrade - you are in trouble - nor do I see any practical method of handling that problem.
Well if you have control over your design simply ensure that you have two banks and can boot from either of them. Upgrading involves booting from one to upgrade the other and then selecting the new bank as the default boot.
Signature · 6 lines
Stuart Lynne <[email protected]> __O <http://www.thinlinux.org> _-\<,_ 604-461-7532 PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 To unsubscribe, send "unsubscribe mtd" to [email protected]